[PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c - Kernel

This is a discussion on [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c - Kernel ; __initdata and const cannot be always a happy pair, as gcc-4.3.3 gives the compile errors like: arch/ia64/xen/xen_pv_ops.c:156: error: xen_init_ops causes a section type conflict arch/ia64/xen/xen_pv_ops.c:340: error: xen_iosapic_ops causes a section type conflict This patch simply removes const from data with ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

  1. [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

    __initdata and const cannot be always a happy pair, as gcc-4.3.3 gives
    the compile errors like:

    arch/ia64/xen/xen_pv_ops.c:156: error: xen_init_ops causes a section type conflict
    arch/ia64/xen/xen_pv_ops.c:340: error: xen_iosapic_ops causes a section type conflict

    This patch simply removes const from data with __initdata.

    Signed-off-by: Takashi Iwai

    ---
    diff --git a/arch/ia64/xen/xen_pv_ops.c b/arch/ia64/xen/xen_pv_ops.c
    index 04cd123..5d491d9 100644
    --- a/arch/ia64/xen/xen_pv_ops.c
    +++ b/arch/ia64/xen/xen_pv_ops.c
    @@ -153,7 +153,7 @@ xen_post_smp_prepare_boot_cpu(void)
    xen_setup_vcpu_info_placement();
    }

    -static const struct pv_init_ops xen_init_ops __initdata = {
    +static struct pv_init_ops xen_init_ops __initdata = {
    .banner = xen_banner,

    .reserve_memory = xen_reserve_memory,
    @@ -260,7 +260,7 @@ xen_intrin_local_irq_restore(unsigned long mask)
    xen_rsm_i();
    }

    -static const struct pv_cpu_ops xen_cpu_ops __initdata = {
    +static struct pv_cpu_ops xen_cpu_ops __initdata = {
    .fc = xen_fc,
    .thash = xen_thash,
    .get_cpuid = xen_get_cpuid,
    @@ -337,7 +337,7 @@ xen_iosapic_write(char __iomem *iosapic, unsigned int reg, u32 val)
    HYPERVISOR_physdev_op(PHYSDEVOP_apic_write, &apic_op);
    }

    -static const struct pv_iosapic_ops xen_iosapic_ops __initdata = {
    +static struct pv_iosapic_ops xen_iosapic_ops __initdata = {
    .pcat_compat_init = xen_pcat_compat_init,
    .__get_irq_chip = xen_iosapic_get_irq_chip,

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

    Takashi Iwai wrote:
    > __initdata and const cannot be always a happy pair, as gcc-4.3.3 gives
    > the compile errors like:
    >
    > arch/ia64/xen/xen_pv_ops.c:156: error: xen_init_ops causes a section type conflict
    > arch/ia64/xen/xen_pv_ops.c:340: error: xen_iosapic_ops causes a section type conflict
    >
    > This patch simply removes const from data with __initdata.
    >


    Yeah, I've seen these sort of messages before, but I don't see why
    there's an inherent problem with having const __initdata.

    Sam?

    J

    > Signed-off-by: Takashi Iwai
    >
    > ---
    > diff --git a/arch/ia64/xen/xen_pv_ops.c b/arch/ia64/xen/xen_pv_ops.c
    > index 04cd123..5d491d9 100644
    > --- a/arch/ia64/xen/xen_pv_ops.c
    > +++ b/arch/ia64/xen/xen_pv_ops.c
    > @@ -153,7 +153,7 @@ xen_post_smp_prepare_boot_cpu(void)
    > xen_setup_vcpu_info_placement();
    > }
    >
    > -static const struct pv_init_ops xen_init_ops __initdata = {
    > +static struct pv_init_ops xen_init_ops __initdata = {
    > .banner = xen_banner,
    >
    > .reserve_memory = xen_reserve_memory,
    > @@ -260,7 +260,7 @@ xen_intrin_local_irq_restore(unsigned long mask)
    > xen_rsm_i();
    > }
    >
    > -static const struct pv_cpu_ops xen_cpu_ops __initdata = {
    > +static struct pv_cpu_ops xen_cpu_ops __initdata = {
    > .fc = xen_fc,
    > .thash = xen_thash,
    > .get_cpuid = xen_get_cpuid,
    > @@ -337,7 +337,7 @@ xen_iosapic_write(char __iomem *iosapic, unsigned int reg, u32 val)
    > HYPERVISOR_physdev_op(PHYSDEVOP_apic_write, &apic_op);
    > }
    >
    > -static const struct pv_iosapic_ops xen_iosapic_ops __initdata = {
    > +static struct pv_iosapic_ops xen_iosapic_ops __initdata = {
    > .pcat_compat_init = xen_pcat_compat_init,
    > .__get_irq_chip = xen_iosapic_get_irq_chip,
    >
    >


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

    At Thu, 06 Nov 2008 10:57:21 -0800,
    Jeremy Fitzhardinge wrote:
    >
    > Takashi Iwai wrote:
    > > __initdata and const cannot be always a happy pair, as gcc-4.3.3 gives
    > > the compile errors like:
    > >
    > > arch/ia64/xen/xen_pv_ops.c:156: error: xen_init_ops causes a section type conflict
    > > arch/ia64/xen/xen_pv_ops.c:340: error: xen_iosapic_ops causes a section type conflict
    > >
    > > This patch simply removes const from data with __initdata.
    > >

    >
    > Yeah, I've seen these sort of messages before, but I don't see why
    > there's an inherent problem with having const __initdata.


    Oh, wait; just looking through linux/init.h, I see we have now
    __initconst. Maybe this is the right choice?

    This would be better documented somewhere in Documentation/*...


    thanks,

    Takashi


    >
    > Sam?
    >
    > J
    >
    > > Signed-off-by: Takashi Iwai
    > >
    > > ---
    > > diff --git a/arch/ia64/xen/xen_pv_ops.c b/arch/ia64/xen/xen_pv_ops.c
    > > index 04cd123..5d491d9 100644
    > > --- a/arch/ia64/xen/xen_pv_ops.c
    > > +++ b/arch/ia64/xen/xen_pv_ops.c
    > > @@ -153,7 +153,7 @@ xen_post_smp_prepare_boot_cpu(void)
    > > xen_setup_vcpu_info_placement();
    > > }
    > >
    > > -static const struct pv_init_ops xen_init_ops __initdata = {
    > > +static struct pv_init_ops xen_init_ops __initdata = {
    > > .banner = xen_banner,
    > >
    > > .reserve_memory = xen_reserve_memory,
    > > @@ -260,7 +260,7 @@ xen_intrin_local_irq_restore(unsigned long mask)
    > > xen_rsm_i();
    > > }
    > >
    > > -static const struct pv_cpu_ops xen_cpu_ops __initdata = {
    > > +static struct pv_cpu_ops xen_cpu_ops __initdata = {
    > > .fc = xen_fc,
    > > .thash = xen_thash,
    > > .get_cpuid = xen_get_cpuid,
    > > @@ -337,7 +337,7 @@ xen_iosapic_write(char __iomem *iosapic, unsigned int reg, u32 val)
    > > HYPERVISOR_physdev_op(PHYSDEVOP_apic_write, &apic_op);
    > > }
    > >
    > > -static const struct pv_iosapic_ops xen_iosapic_ops __initdata = {
    > > +static struct pv_iosapic_ops xen_iosapic_ops __initdata = {
    > > .pcat_compat_init = xen_pcat_compat_init,
    > > .__get_irq_chip = xen_iosapic_get_irq_chip,
    > >
    > >

    >

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

    On Thu, Nov 06, 2008 at 10:57:21AM -0800, Jeremy Fitzhardinge wrote:
    > Takashi Iwai wrote:
    > >__initdata and const cannot be always a happy pair, as gcc-4.3.3 gives
    > >the compile errors like:
    > >
    > > arch/ia64/xen/xen_pv_ops.c:156: error: xen_init_ops causes a section
    > > type conflict
    > > arch/ia64/xen/xen_pv_ops.c:340: error: xen_iosapic_ops causes a section
    > > type conflict
    > >
    > >This patch simply removes const from data with __initdata.
    > >

    >
    > Yeah, I've seen these sort of messages before, but I don't see why
    > there's an inherent problem with having const __initdata.
    >
    > Sam?


    The root problem here is that in some cases gcc will stuff this into
    a section marked CONST and in other cases not.
    So when we manually specify the section we better not mix const and
    non-const stuff in the same section.
    The problem is that it is very gcc dependent. I have with powerpc
    seen that the same code was not put in CONST with a 32 bit build,
    but with the 64 bit build it was.
    The only cure was to remove the const and use initdata.
    You can try to play with initconst - and it may work.
    But you need to have pretty good build coverage to be sure.

    Sam
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

    At Thu, 6 Nov 2008 22:48:48 +0100,
    Sam Ravnborg wrote:
    >
    > On Thu, Nov 06, 2008 at 10:57:21AM -0800, Jeremy Fitzhardinge wrote:
    > > Takashi Iwai wrote:
    > > >__initdata and const cannot be always a happy pair, as gcc-4.3.3 gives
    > > >the compile errors like:
    > > >
    > > > arch/ia64/xen/xen_pv_ops.c:156: error: xen_init_ops causes a section
    > > > type conflict
    > > > arch/ia64/xen/xen_pv_ops.c:340: error: xen_iosapic_ops causes a section
    > > > type conflict
    > > >
    > > >This patch simply removes const from data with __initdata.
    > > >

    > >
    > > Yeah, I've seen these sort of messages before, but I don't see why
    > > there's an inherent problem with having const __initdata.
    > >
    > > Sam?

    >
    > The root problem here is that in some cases gcc will stuff this into
    > a section marked CONST and in other cases not.
    > So when we manually specify the section we better not mix const and
    > non-const stuff in the same section.
    > The problem is that it is very gcc dependent. I have with powerpc
    > seen that the same code was not put in CONST with a 32 bit build,
    > but with the 64 bit build it was.
    > The only cure was to remove the const and use initdata.
    > You can try to play with initconst - and it may work.
    > But you need to have pretty good build coverage to be sure.


    OK, then my original patch should do right
    Do you guys see any problems with it?

    Right now 2.6.28-rc kernel doesn't build, thus this is basically a
    regression.


    thanks,

    Takashi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

    At Tue, 11 Nov 2008 17:15:52 +0900,
    Isaku Yamahata wrote:
    >
    > On Tue, Nov 11, 2008 at 08:51:11AM +0100, Takashi Iwai wrote:
    > > At Thu, 6 Nov 2008 22:48:48 +0100,
    > > Sam Ravnborg wrote:
    > > >
    > > > On Thu, Nov 06, 2008 at 10:57:21AM -0800, Jeremy Fitzhardinge wrote:
    > > > > Takashi Iwai wrote:
    > > > > >__initdata and const cannot be always a happy pair, as gcc-4.3.3 gives
    > > > > >the compile errors like:
    > > > > >
    > > > > > arch/ia64/xen/xen_pv_ops.c:156: error: xen_init_ops causes a section
    > > > > > type conflict
    > > > > > arch/ia64/xen/xen_pv_ops.c:340: error: xen_iosapic_ops causes a section
    > > > > > type conflict
    > > > > >
    > > > > >This patch simply removes const from data with __initdata.
    > > > > >
    > > > >
    > > > > Yeah, I've seen these sort of messages before, but I don't see why
    > > > > there's an inherent problem with having const __initdata.
    > > > >
    > > > > Sam?
    > > >
    > > > The root problem here is that in some cases gcc will stuff this into
    > > > a section marked CONST and in other cases not.
    > > > So when we manually specify the section we better not mix const and
    > > > non-const stuff in the same section.
    > > > The problem is that it is very gcc dependent. I have with powerpc
    > > > seen that the same code was not put in CONST with a 32 bit build,
    > > > but with the 64 bit build it was.
    > > > The only cure was to remove the const and use initdata.
    > > > You can try to play with initconst - and it may work.
    > > > But you need to have pretty good build coverage to be sure.

    > >
    > > OK, then my original patch should do right
    > > Do you guys see any problems with it?
    > >
    > > Right now 2.6.28-rc kernel doesn't build, thus this is basically a
    > > regression.

    >
    > I'm fine with the patch.
    >
    > The above sounds x86 xen potentially has the same issue, though.
    >
    > linux-2.6/arch/x86/xen $ grep __initdata *
    > enlighten.c:static const struct pv_info xen_info __initdata = {
    > enlighten.c:static const struct pv_init_ops xen_init_ops __initdata = {
    > enlighten.c:static const struct pv_time_ops xen_time_ops __initdata = {
    > enlighten.c:static const struct pv_cpu_ops xen_cpu_ops __initdata = {
    > enlighten.c:static const struct pv_apic_ops xen_apic_ops __initdata = {
    > enlighten.c:static const struct pv_mmu_ops xen_mmu_ops __initdata = {
    > enlighten.c:static const struct machine_ops __initdata xen_machine_ops = {
    > irq.c:static const struct pv_irq_ops xen_irq_ops __initdata = {
    > smp.c:static const struct smp_ops xen_smp_ops __initdata = {


    Oh, care to create a patch?


    thanks,

    Takashi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

    On Tue, Nov 11, 2008 at 08:51:11AM +0100, Takashi Iwai wrote:
    > At Thu, 6 Nov 2008 22:48:48 +0100,
    > Sam Ravnborg wrote:
    > >
    > > On Thu, Nov 06, 2008 at 10:57:21AM -0800, Jeremy Fitzhardinge wrote:
    > > > Takashi Iwai wrote:
    > > > >__initdata and const cannot be always a happy pair, as gcc-4.3.3 gives
    > > > >the compile errors like:
    > > > >
    > > > > arch/ia64/xen/xen_pv_ops.c:156: error: xen_init_ops causes a section
    > > > > type conflict
    > > > > arch/ia64/xen/xen_pv_ops.c:340: error: xen_iosapic_ops causes a section
    > > > > type conflict
    > > > >
    > > > >This patch simply removes const from data with __initdata.
    > > > >
    > > >
    > > > Yeah, I've seen these sort of messages before, but I don't see why
    > > > there's an inherent problem with having const __initdata.
    > > >
    > > > Sam?

    > >
    > > The root problem here is that in some cases gcc will stuff this into
    > > a section marked CONST and in other cases not.
    > > So when we manually specify the section we better not mix const and
    > > non-const stuff in the same section.
    > > The problem is that it is very gcc dependent. I have with powerpc
    > > seen that the same code was not put in CONST with a 32 bit build,
    > > but with the 64 bit build it was.
    > > The only cure was to remove the const and use initdata.
    > > You can try to play with initconst - and it may work.
    > > But you need to have pretty good build coverage to be sure.

    >
    > OK, then my original patch should do right
    > Do you guys see any problems with it?
    >
    > Right now 2.6.28-rc kernel doesn't build, thus this is basically a
    > regression.


    I'm fine with the patch.

    The above sounds x86 xen potentially has the same issue, though.

    linux-2.6/arch/x86/xen $ grep __initdata *
    enlighten.c:static const struct pv_info xen_info __initdata = {
    enlighten.c:static const struct pv_init_ops xen_init_ops __initdata = {
    enlighten.c:static const struct pv_time_ops xen_time_ops __initdata = {
    enlighten.c:static const struct pv_cpu_ops xen_cpu_ops __initdata = {
    enlighten.c:static const struct pv_apic_ops xen_apic_ops __initdata = {
    enlighten.c:static const struct pv_mmu_ops xen_mmu_ops __initdata = {
    enlighten.c:static const struct machine_ops __initdata xen_machine_ops = {
    irq.c:static const struct pv_irq_ops xen_irq_ops __initdata = {
    smp.c:static const struct smp_ops xen_smp_ops __initdata = {

    thanks,
    --
    yamahata
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

    On Tue, Nov 11, 2008 at 09:18:50AM +0100, Takashi Iwai wrote:
    > At Tue, 11 Nov 2008 17:15:52 +0900,
    > Isaku Yamahata wrote:
    > >
    > > On Tue, Nov 11, 2008 at 08:51:11AM +0100, Takashi Iwai wrote:
    > > > At Thu, 6 Nov 2008 22:48:48 +0100,
    > > > Sam Ravnborg wrote:
    > > > >
    > > > > On Thu, Nov 06, 2008 at 10:57:21AM -0800, Jeremy Fitzhardinge wrote:
    > > > > > Takashi Iwai wrote:
    > > > > > >__initdata and const cannot be always a happy pair, as gcc-4.3.3 gives
    > > > > > >the compile errors like:
    > > > > > >
    > > > > > > arch/ia64/xen/xen_pv_ops.c:156: error: xen_init_ops causes a section
    > > > > > > type conflict
    > > > > > > arch/ia64/xen/xen_pv_ops.c:340: error: xen_iosapic_ops causes a section
    > > > > > > type conflict
    > > > > > >
    > > > > > >This patch simply removes const from data with __initdata.
    > > > > > >
    > > > > >
    > > > > > Yeah, I've seen these sort of messages before, but I don't see why
    > > > > > there's an inherent problem with having const __initdata.
    > > > > >
    > > > > > Sam?
    > > > >
    > > > > The root problem here is that in some cases gcc will stuff this into
    > > > > a section marked CONST and in other cases not.
    > > > > So when we manually specify the section we better not mix const and
    > > > > non-const stuff in the same section.
    > > > > The problem is that it is very gcc dependent. I have with powerpc
    > > > > seen that the same code was not put in CONST with a 32 bit build,
    > > > > but with the 64 bit build it was.
    > > > > The only cure was to remove the const and use initdata.
    > > > > You can try to play with initconst - and it may work.
    > > > > But you need to have pretty good build coverage to be sure.
    > > >
    > > > OK, then my original patch should do right
    > > > Do you guys see any problems with it?
    > > >
    > > > Right now 2.6.28-rc kernel doesn't build, thus this is basically a
    > > > regression.

    > >
    > > I'm fine with the patch.
    > >
    > > The above sounds x86 xen potentially has the same issue, though.
    > >
    > > linux-2.6/arch/x86/xen $ grep __initdata *
    > > enlighten.c:static const struct pv_info xen_info __initdata = {
    > > enlighten.c:static const struct pv_init_ops xen_init_ops __initdata = {
    > > enlighten.c:static const struct pv_time_ops xen_time_ops __initdata = {
    > > enlighten.c:static const struct pv_cpu_ops xen_cpu_ops __initdata = {
    > > enlighten.c:static const struct pv_apic_ops xen_apic_ops __initdata = {
    > > enlighten.c:static const struct pv_mmu_ops xen_mmu_ops __initdata = {
    > > enlighten.c:static const struct machine_ops __initdata xen_machine_ops = {
    > > irq.c:static const struct pv_irq_ops xen_irq_ops __initdata = {
    > > smp.c:static const struct smp_ops xen_smp_ops __initdata = {

    >
    > Oh, care to create a patch?


    Here is.

    __initdata and const cannot be always a happy pair and
    x86 xen has the potential issue.
    This patch simply removes const from data with __initdata
    under arch/x86/xen/.

    Signed-off-by: Isaku Yamahata

    diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
    index 0013a72..19f758c 100644
    --- a/arch/x86/xen/enlighten.c
    +++ b/arch/x86/xen/enlighten.c
    @@ -1173,14 +1173,14 @@ static void xen_set_fixmap(unsigned idx, unsigned long phys, pgprot_t prot)
    #endif
    }

    -static const struct pv_info xen_info __initdata = {
    +static struct pv_info xen_info __initdata = {
    .paravirt_enabled = 1,
    .shared_kernel_pmd = 0,

    .name = "Xen",
    };

    -static const struct pv_init_ops xen_init_ops __initdata = {
    +static struct pv_init_ops xen_init_ops __initdata = {
    .patch = xen_patch,

    .banner = xen_banner,
    @@ -1189,7 +1189,7 @@ static const struct pv_init_ops xen_init_ops __initdata = {
    .post_allocator_init = xen_post_allocator_init,
    };

    -static const struct pv_time_ops xen_time_ops __initdata = {
    +static struct pv_time_ops xen_time_ops __initdata = {
    .time_init = xen_time_init,

    .set_wallclock = xen_set_wallclock,
    @@ -1198,7 +1198,7 @@ static const struct pv_time_ops xen_time_ops __initdata = {
    .sched_clock = xen_sched_clock,
    };

    -static const struct pv_cpu_ops xen_cpu_ops __initdata = {
    +static struct pv_cpu_ops xen_cpu_ops __initdata = {
    .cpuid = xen_cpuid,

    .set_debugreg = xen_set_debugreg,
    @@ -1260,7 +1260,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initdata = {
    },
    };

    -static const struct pv_apic_ops xen_apic_ops __initdata = {
    +static struct pv_apic_ops xen_apic_ops __initdata = {
    #ifdef CONFIG_X86_LOCAL_APIC
    .setup_boot_clock = paravirt_nop,
    .setup_secondary_clock = paravirt_nop,
    @@ -1268,7 +1268,7 @@ static const struct pv_apic_ops xen_apic_ops __initdata = {
    #endif
    };

    -static const struct pv_mmu_ops xen_mmu_ops __initdata = {
    +static struct pv_mmu_ops xen_mmu_ops __initdata = {
    .pagetable_setup_start = xen_pagetable_setup_start,
    .pagetable_setup_done = xen_pagetable_setup_done,

    @@ -1381,7 +1381,7 @@ static void xen_crash_shutdown(struct pt_regs *regs)
    xen_reboot(SHUTDOWN_crash);
    }

    -static const struct machine_ops __initdata xen_machine_ops = {
    +static struct machine_ops __initdata xen_machine_ops = {
    .restart = xen_restart,
    .halt = xen_machine_halt,
    .power_off = xen_machine_halt,
    diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
    index 28b85ab..ffadf3a 100644
    --- a/arch/x86/xen/irq.c
    +++ b/arch/x86/xen/irq.c
    @@ -124,7 +124,7 @@ static void xen_halt(void)
    xen_safe_halt();
    }

    -static const struct pv_irq_ops xen_irq_ops __initdata = {
    +static struct pv_irq_ops xen_irq_ops __initdata = {
    .init_IRQ = __xen_init_IRQ,
    .save_fl = xen_save_fl,
    .restore_fl = xen_restore_fl,
    diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
    index d77da61..f0a1ea3 100644
    --- a/arch/x86/xen/smp.c
    +++ b/arch/x86/xen/smp.c
    @@ -466,7 +466,7 @@ static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id)
    return IRQ_HANDLED;
    }

    -static const struct smp_ops xen_smp_ops __initdata = {
    +static struct smp_ops xen_smp_ops __initdata = {
    .smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu,
    .smp_prepare_cpus = xen_smp_prepare_cpus,
    .smp_cpus_done = xen_smp_cpus_done,


    --
    yamahata
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

    At Tue, 11 Nov 2008 09:43:27 -0800,
    Jeremy Fitzhardinge wrote:
    >
    > Isaku Yamahata wrote:
    > > Here is.
    > >
    > > __initdata and const cannot be always a happy pair and
    > > x86 xen has the potential issue.
    > > This patch simply removes const from data with __initdata
    > > under arch/x86/xen/.
    > >

    >
    > No, I think the proper fix is to use __initconst.


    The problem is that it depends on gcc version which section it goes.
    Thus __initconst could break some gcc versions as well.


    Takashi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

    Isaku Yamahata wrote:
    > Here is.
    >
    > __initdata and const cannot be always a happy pair and
    > x86 xen has the potential issue.
    > This patch simply removes const from data with __initdata
    > under arch/x86/xen/.
    >


    No, I think the proper fix is to use __initconst.

    J
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

    Takashi Iwai wrote:
    > At Tue, 11 Nov 2008 09:43:27 -0800,
    > Jeremy Fitzhardinge wrote:
    >
    >> Isaku Yamahata wrote:
    >>
    >>> Here is.
    >>>
    >>> __initdata and const cannot be always a happy pair and
    >>> x86 xen has the potential issue.
    >>> This patch simply removes const from data with __initdata
    >>> under arch/x86/xen/.
    >>>
    >>>

    >> No, I think the proper fix is to use __initconst.
    >>

    >
    > The problem is that it depends on gcc version which section it goes.
    > Thus __initconst could break some gcc versions as well.
    >


    Why? __initconst explicitly puts it in .init.rodata.

    J
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c

    At Tue, 11 Nov 2008 10:47:24 -0800,
    Jeremy Fitzhardinge wrote:
    >
    > Takashi Iwai wrote:
    > > At Tue, 11 Nov 2008 09:43:27 -0800,
    > > Jeremy Fitzhardinge wrote:
    > >
    > >> Isaku Yamahata wrote:
    > >>
    > >>> Here is.
    > >>>
    > >>> __initdata and const cannot be always a happy pair and
    > >>> x86 xen has the potential issue.
    > >>> This patch simply removes const from data with __initdata
    > >>> under arch/x86/xen/.
    > >>>
    > >>>
    > >> No, I think the proper fix is to use __initconst.
    > >>

    > >
    > > The problem is that it depends on gcc version which section it goes.
    > > Thus __initconst could break some gcc versions as well.
    > >

    >
    > Why? __initconst explicitly puts it in .init.rodata.


    Hrm, right, that's what __initconst does. Just confused.
    Then I'm wondering in which case __initconst can be broken...
    Sam? Do you have any particular reports?


    Takashi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread