* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7. [not found] ` <49BA3B05.9020906@snapgear.com> @ 2009-03-13 12:14 ` Geert Uytterhoeven 2009-03-16 12:40 ` Greg Ungerer [not found] ` <49BE48B3.6060108@snapgear.com> 0 siblings, 2 replies; 12+ messages in thread From: Geert Uytterhoeven @ 2009-03-13 12:14 UTC (permalink / raw) To: Greg Ungerer Cc: Sam Ravnborg, Rob Landley, linux-kernel, dwmw2, linux-next, linux-m68k On Fri, Mar 13, 2009 at 11:52, Greg Ungerer <gerg@snapgear.com> wrote: > Sam Ravnborg wrote: >> On Fri, Mar 13, 2009 at 09:33:18AM +0100, Geert Uytterhoeven wrote: >>> On Fri, Mar 13, 2009 at 09:25, Sam Ravnborg <sam@ravnborg.org> wrote: >>>> On Fri, Mar 13, 2009 at 05:04:57PM +1000, Greg Ungerer wrote: >>>>> I pretty quick time I can fix up the last couple on the above list. >>>>> But do we want to put all that change into 2.6.29-rc at this point? >>>> >>>> In general we do not want to have headers_check broken in mainline, >>> >>> headers_check is not broken, headers_install is. >>> >>> Hmm, in some sense headers_check _is_ broken, as it doesn't notice >>> headers_install >>> installs headers that refer to other headers that are not installed... >> >> This is what scripts/headers_check are supposed to do - strange. >> >>> Greg, I had a quick look at your signcontext.h and signal.h merge, and >>> the MMU >>> part seems to be OK. >>> >>> However, some of the installed headers still have checks for CONFIG_MMU: >>> >>> param.h:#ifdef CONFIG_MMU >>> sigcontext.h:#ifndef CONFIG_MMU >>> sigcontext.h:#ifdef CONFIG_MMU >>> siginfo.h:#ifdef CONFIG_MMU >>> siginfo.h:#ifdef CONFIG_MMU >>> siginfo.h:#endif /* CONFIG_MMU */ >>> swab.h:#elif defined(CONFIG_MMU) >>> >>> so these have to be added to the generic unifdef-y list (is that >>> include/asm-generic/Kbuild.asm?). > > Hmmm, yes your right. > > >> include/asm-generic/Kbuild.asm impacts all architectures so be carefull >> there. >> It looks like some updates to arch/m68k/include/asm/Kbuild is needed, >> and not the generic list of files to export. >> >> Also use og CONFIG_MMU suprises me. >> We used #ifdef __uClinux__ in the non-merged headers to avoid use >> of a CONFIG_* symbol that is not valid outside the kernel namespace. >> So if param.h in m68k uses CONFIG_MMU it is broken. > > I have been trying to use CONFIG_MMU wherever possible (so for non- > exported headers), since that matches what is actually in the code > proper. I am concerned at the longer term use of __uClinux__ for > distinguishing MMU and non-MMU. I plan on switching to use a normal > m68k toolchain soon. And it won't define __uClinux__ on its own. > (I already do this on ARM for example - same toolchain on both > MMU an non-MMU). > > What I have done so far is or the most part a very simple merge > of the files. I know there is room for some improvements in quite a > few of these files. > > The use of CONFIG_MMU in swab.h (is this actually exported to user > space?) is not actually for code that is MMU or non-MMU. It is > actually architecture specific. Most ColdFire parts don't have the > "rolw" instruction. The condition test can be better. Geert, any > ideas on what is more appropriate here? The `rolw' variant is already protected by `#if defined (__mcfisaaplus__) || defined (__mcfisac__)', so I think you can replace the `#elif defined(CONFIG_MMU)' by a plain `#else'. Or are there cases where you don't want to have __arch_swab32 at all? > I can switch back to using __uClinux__ on siginfo.h and sigcontext.h. > If I am not mistaken we can't change these structures without breaking > backwards compatibility? The sigcontext change is particularly ugly :-( Copying the signal experts on linux-m68k... > Similarly for param.h, it looks like a switch back to using > __uClinux__ for now is the only option. > > Now after these fixups should I create a git branch with these header > merges in for inclusion into 2.6.29-rc? To fix the regression we > only need to do the handful of files that Rob listed, right? Yes. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7. 2009-03-13 12:14 ` make headers_install broken for ARCH=m68k in 2.6.29-rc7 Geert Uytterhoeven @ 2009-03-16 12:40 ` Greg Ungerer [not found] ` <49BE48B3.6060108@snapgear.com> 1 sibling, 0 replies; 12+ messages in thread From: Greg Ungerer @ 2009-03-16 12:40 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Sam Ravnborg, Rob Landley, linux-kernel, dwmw2, linux-next, linux-m68k Geert Uytterhoeven wrote: > On Fri, Mar 13, 2009 at 11:52, Greg Ungerer <gerg@snapgear.com> wrote: >> Sam Ravnborg wrote: >>> On Fri, Mar 13, 2009 at 09:33:18AM +0100, Geert Uytterhoeven wrote: >>>> On Fri, Mar 13, 2009 at 09:25, Sam Ravnborg <sam@ravnborg.org> wrote: >>>>> On Fri, Mar 13, 2009 at 05:04:57PM +1000, Greg Ungerer wrote: >>>>>> I pretty quick time I can fix up the last couple on the above list. >>>>>> But do we want to put all that change into 2.6.29-rc at this point? >>>>> In general we do not want to have headers_check broken in mainline, >>>> headers_check is not broken, headers_install is. >>>> >>>> Hmm, in some sense headers_check _is_ broken, as it doesn't notice >>>> headers_install >>>> installs headers that refer to other headers that are not installed... >>> This is what scripts/headers_check are supposed to do - strange. >>> >>>> Greg, I had a quick look at your signcontext.h and signal.h merge, and >>>> the MMU >>>> part seems to be OK. >>>> >>>> However, some of the installed headers still have checks for CONFIG_MMU: >>>> >>>> param.h:#ifdef CONFIG_MMU >>>> sigcontext.h:#ifndef CONFIG_MMU >>>> sigcontext.h:#ifdef CONFIG_MMU >>>> siginfo.h:#ifdef CONFIG_MMU >>>> siginfo.h:#ifdef CONFIG_MMU >>>> siginfo.h:#endif /* CONFIG_MMU */ >>>> swab.h:#elif defined(CONFIG_MMU) >>>> >>>> so these have to be added to the generic unifdef-y list (is that >>>> include/asm-generic/Kbuild.asm?). >> Hmmm, yes your right. >> >> >>> include/asm-generic/Kbuild.asm impacts all architectures so be carefull >>> there. >>> It looks like some updates to arch/m68k/include/asm/Kbuild is needed, >>> and not the generic list of files to export. >>> >>> Also use og CONFIG_MMU suprises me. >>> We used #ifdef __uClinux__ in the non-merged headers to avoid use >>> of a CONFIG_* symbol that is not valid outside the kernel namespace. >>> So if param.h in m68k uses CONFIG_MMU it is broken. >> I have been trying to use CONFIG_MMU wherever possible (so for non- >> exported headers), since that matches what is actually in the code >> proper. I am concerned at the longer term use of __uClinux__ for >> distinguishing MMU and non-MMU. I plan on switching to use a normal >> m68k toolchain soon. And it won't define __uClinux__ on its own. >> (I already do this on ARM for example - same toolchain on both >> MMU an non-MMU). >> >> What I have done so far is or the most part a very simple merge >> of the files. I know there is room for some improvements in quite a >> few of these files. >> >> The use of CONFIG_MMU in swab.h (is this actually exported to user >> space?) is not actually for code that is MMU or non-MMU. It is >> actually architecture specific. Most ColdFire parts don't have the >> "rolw" instruction. The condition test can be better. Geert, any >> ideas on what is more appropriate here? > > The `rolw' variant is already protected by `#if defined > (__mcfisaaplus__) || defined (__mcfisac__)', > so I think you can replace the `#elif defined(CONFIG_MMU)' by a plain `#else'. > Or are there cases where you don't want to have __arch_swab32 at all? Not all ColdFire fit into '(__mcfisaaplus__) || defined (__mcfisac__)' so #else won't be good enough. Though I suspect it is true that the older m68k varients (68328, etc) can do "rolw" - or I am I mistaken on that? >> I can switch back to using __uClinux__ on siginfo.h and sigcontext.h. >> If I am not mistaken we can't change these structures without breaking >> backwards compatibility? The sigcontext change is particularly ugly :-( > > Copying the signal experts on linux-m68k... > >> Similarly for param.h, it looks like a switch back to using >> __uClinux__ for now is the only option. >> >> Now after these fixups should I create a git branch with these header >> merges in for inclusion into 2.6.29-rc? To fix the regression we >> only need to do the handful of files that Rob listed, right? > > Yes. Ok, I have created a git branch for this as: The following changes since commit 5bee17f18b595937e6beafeee5197868a3f74a06: Kyle McMartin (1): parisc: sba_iommu: fix build bug when CONFIG_PARISC_AGP=y are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git fix-includes Greg Ungerer (8): m68k: merge the non-MMU and MMU versions of param.h m68k: merge the non-MMU and MMU versions of swab.h m68k: merge the non-MMU and MMU versions of sigcontext.h m68k: merge the non-MMU and MMU versions of siginfo.h m68k: use MMU version of setup.h for both MMU and non-MMU m68k: merge the non-MMU and MMU versions of ptrace.h m68k: merge the non-MMU and MMU versions of signal.h m68k: use the MMU version of unistd.h for all m68k platforms arch/m68k/include/asm/param.h | 25 ++- arch/m68k/include/asm/param_mm.h | 22 -- arch/m68k/include/asm/param_no.h | 22 -- arch/m68k/include/asm/ptrace.h | 88 ++++++++- arch/m68k/include/asm/ptrace_mm.h | 80 ------- arch/m68k/include/asm/ptrace_no.h | 87 -------- arch/m68k/include/asm/setup.h | 377 ++++++++++++++++++++++++++++++++- arch/m68k/include/asm/setup_mm.h | 376 -------------------------------- arch/m68k/include/asm/setup_no.h | 10 - arch/m68k/include/asm/sigcontext.h | 25 ++- arch/m68k/include/asm/sigcontext_mm.h | 19 -- arch/m68k/include/asm/sigcontext_no.h | 17 -- arch/m68k/include/asm/siginfo.h | 95 ++++++++- arch/m68k/include/asm/siginfo_mm.h | 92 -------- arch/m68k/include/asm/siginfo_no.h | 6 - arch/m68k/include/asm/signal.h | 216 ++++++++++++++++++- arch/m68k/include/asm/signal_mm.h | 206 ------------------ arch/m68k/include/asm/signal_no.h | 159 -------------- arch/m68k/include/asm/swab.h | 30 +++- arch/m68k/include/asm/swab_mm.h | 16 -- arch/m68k/include/asm/swab_no.h | 24 -- arch/m68k/include/asm/unistd.h | 377 ++++++++++++++++++++++++++++++++- arch/m68k/include/asm/unistd_mm.h | 372 -------------------------------- arch/m68k/include/asm/unistd_no.h | 372 -------------------------------- 24 files changed, 1206 insertions(+), 1907 deletions(-) delete mode 100644 arch/m68k/include/asm/param_mm.h delete mode 100644 arch/m68k/include/asm/param_no.h delete mode 100644 arch/m68k/include/asm/ptrace_mm.h delete mode 100644 arch/m68k/include/asm/ptrace_no.h delete mode 100644 arch/m68k/include/asm/setup_mm.h delete mode 100644 arch/m68k/include/asm/setup_no.h delete mode 100644 arch/m68k/include/asm/sigcontext_mm.h delete mode 100644 arch/m68k/include/asm/sigcontext_no.h delete mode 100644 arch/m68k/include/asm/siginfo_mm.h delete mode 100644 arch/m68k/include/asm/siginfo_no.h delete mode 100644 arch/m68k/include/asm/signal_mm.h delete mode 100644 arch/m68k/include/asm/signal_no.h delete mode 100644 arch/m68k/include/asm/swab_mm.h delete mode 100644 arch/m68k/include/asm/swab_no.h delete mode 100644 arch/m68k/include/asm/unistd_mm.h delete mode 100644 arch/m68k/include/asm/unistd_no.h I have only patched those files that I saw mentioned in the previous emails in this thread. Geert, can you check an m68k build? Rob, can you check that you can build what you used to be able to? Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <49BE48B3.6060108@snapgear.com>]
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7. [not found] ` <49BE48B3.6060108@snapgear.com> @ 2009-03-16 20:20 ` Rob Landley [not found] ` <200903161521.00036.rob@landley.net> 1 sibling, 0 replies; 12+ messages in thread From: Rob Landley @ 2009-03-16 20:20 UTC (permalink / raw) To: Greg Ungerer Cc: Geert Uytterhoeven, Sam Ravnborg, linux-kernel, dwmw2, linux-next, linux-m68k On Monday 16 March 2009 07:40:19 Greg Ungerer wrote: > Geert Uytterhoeven wrote: > > On Fri, Mar 13, 2009 at 11:52, Greg Ungerer <gerg@snapgear.com> wrote: > >> Sam Ravnborg wrote: > >>> On Fri, Mar 13, 2009 at 09:33:18AM +0100, Geert Uytterhoeven wrote: > >>>> On Fri, Mar 13, 2009 at 09:25, Sam Ravnborg <sam@ravnborg.org> wrote: > >>>>> On Fri, Mar 13, 2009 at 05:04:57PM +1000, Greg Ungerer wrote: > >>>>>> I pretty quick time I can fix up the last couple on the above list. > >>>>>> But do we want to put all that change into 2.6.29-rc at this point? > >>>>> > >>>>> In general we do not want to have headers_check broken in mainline, > >>>> > >>>> headers_check is not broken, headers_install is. > >>>> > >>>> Hmm, in some sense headers_check _is_ broken, as it doesn't notice > >>>> headers_install > >>>> installs headers that refer to other headers that are not installed... > >>> > >>> This is what scripts/headers_check are supposed to do - strange. > >>> > >>>> Greg, I had a quick look at your signcontext.h and signal.h merge, and > >>>> the MMU > >>>> part seems to be OK. > >>>> > >>>> However, some of the installed headers still have checks for > >>>> CONFIG_MMU: > >>>> > >>>> param.h:#ifdef CONFIG_MMU > >>>> sigcontext.h:#ifndef CONFIG_MMU > >>>> sigcontext.h:#ifdef CONFIG_MMU > >>>> siginfo.h:#ifdef CONFIG_MMU > >>>> siginfo.h:#ifdef CONFIG_MMU > >>>> siginfo.h:#endif /* CONFIG_MMU */ > >>>> swab.h:#elif defined(CONFIG_MMU) > >>>> > >>>> so these have to be added to the generic unifdef-y list (is that > >>>> include/asm-generic/Kbuild.asm?). > >> > >> Hmmm, yes your right. > >> > >>> include/asm-generic/Kbuild.asm impacts all architectures so be carefull > >>> there. > >>> It looks like some updates to arch/m68k/include/asm/Kbuild is needed, > >>> and not the generic list of files to export. > >>> > >>> Also use og CONFIG_MMU suprises me. > >>> We used #ifdef __uClinux__ in the non-merged headers to avoid use > >>> of a CONFIG_* symbol that is not valid outside the kernel namespace. > >>> So if param.h in m68k uses CONFIG_MMU it is broken. > >> > >> I have been trying to use CONFIG_MMU wherever possible (so for non- > >> exported headers), since that matches what is actually in the code > >> proper. I am concerned at the longer term use of __uClinux__ for > >> distinguishing MMU and non-MMU. I plan on switching to use a normal > >> m68k toolchain soon. And it won't define __uClinux__ on its own. > >> (I already do this on ARM for example - same toolchain on both > >> MMU an non-MMU). > >> > >> What I have done so far is or the most part a very simple merge > >> of the files. I know there is room for some improvements in quite a > >> few of these files. > >> > >> The use of CONFIG_MMU in swab.h (is this actually exported to user > >> space?) is not actually for code that is MMU or non-MMU. It is > >> actually architecture specific. Most ColdFire parts don't have the > >> "rolw" instruction. The condition test can be better. Geert, any > >> ideas on what is more appropriate here? > > > > The `rolw' variant is already protected by `#if defined > > (__mcfisaaplus__) || defined (__mcfisac__)', > > so I think you can replace the `#elif defined(CONFIG_MMU)' by a plain > > `#else'. Or are there cases where you don't want to have __arch_swab32 at > > all? > > Not all ColdFire fit into '(__mcfisaaplus__) || defined (__mcfisac__)' > so #else won't be good enough. Though I suspect it is true that the > older m68k varients (68328, etc) can do "rolw" - or I am I mistaken on > that? > > >> I can switch back to using __uClinux__ on siginfo.h and sigcontext.h. > >> If I am not mistaken we can't change these structures without breaking > >> backwards compatibility? The sigcontext change is particularly ugly :-( > > > > Copying the signal experts on linux-m68k... > > > >> Similarly for param.h, it looks like a switch back to using > >> __uClinux__ for now is the only option. > >> > >> Now after these fixups should I create a git branch with these header > >> merges in for inclusion into 2.6.29-rc? To fix the regression we > >> only need to do the handful of files that Rob listed, right? > > > > Yes. > > Ok, I have created a git branch for this as: > > The following changes since commit > 5bee17f18b595937e6beafeee5197868a3f74a06: Kyle McMartin (1): > parisc: sba_iommu: fix build bug when CONFIG_PARISC_AGP=y > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git > fix-includes > > Greg Ungerer (8): > m68k: merge the non-MMU and MMU versions of param.h > m68k: merge the non-MMU and MMU versions of swab.h > m68k: merge the non-MMU and MMU versions of sigcontext.h > m68k: merge the non-MMU and MMU versions of siginfo.h > m68k: use MMU version of setup.h for both MMU and non-MMU > m68k: merge the non-MMU and MMU versions of ptrace.h > m68k: merge the non-MMU and MMU versions of signal.h > m68k: use the MMU version of unistd.h for all m68k platforms > > arch/m68k/include/asm/param.h | 25 ++- > arch/m68k/include/asm/param_mm.h | 22 -- > arch/m68k/include/asm/param_no.h | 22 -- > arch/m68k/include/asm/ptrace.h | 88 ++++++++- > arch/m68k/include/asm/ptrace_mm.h | 80 ------- > arch/m68k/include/asm/ptrace_no.h | 87 -------- > arch/m68k/include/asm/setup.h | 377 > ++++++++++++++++++++++++++++++++- > arch/m68k/include/asm/setup_mm.h | 376 > -------------------------------- > arch/m68k/include/asm/setup_no.h | 10 - > arch/m68k/include/asm/sigcontext.h | 25 ++- > arch/m68k/include/asm/sigcontext_mm.h | 19 -- > arch/m68k/include/asm/sigcontext_no.h | 17 -- > arch/m68k/include/asm/siginfo.h | 95 ++++++++- > arch/m68k/include/asm/siginfo_mm.h | 92 -------- > arch/m68k/include/asm/siginfo_no.h | 6 - > arch/m68k/include/asm/signal.h | 216 ++++++++++++++++++- > arch/m68k/include/asm/signal_mm.h | 206 ------------------ > arch/m68k/include/asm/signal_no.h | 159 -------------- > arch/m68k/include/asm/swab.h | 30 +++- > arch/m68k/include/asm/swab_mm.h | 16 -- > arch/m68k/include/asm/swab_no.h | 24 -- > arch/m68k/include/asm/unistd.h | 377 > ++++++++++++++++++++++++++++++++- > arch/m68k/include/asm/unistd_mm.h | 372 > -------------------------------- > arch/m68k/include/asm/unistd_no.h | 372 > -------------------------------- > 24 files changed, 1206 insertions(+), 1907 deletions(-) > delete mode 100644 arch/m68k/include/asm/param_mm.h > delete mode 100644 arch/m68k/include/asm/param_no.h > delete mode 100644 arch/m68k/include/asm/ptrace_mm.h > delete mode 100644 arch/m68k/include/asm/ptrace_no.h > delete mode 100644 arch/m68k/include/asm/setup_mm.h > delete mode 100644 arch/m68k/include/asm/setup_no.h > delete mode 100644 arch/m68k/include/asm/sigcontext_mm.h > delete mode 100644 arch/m68k/include/asm/sigcontext_no.h > delete mode 100644 arch/m68k/include/asm/siginfo_mm.h > delete mode 100644 arch/m68k/include/asm/siginfo_no.h > delete mode 100644 arch/m68k/include/asm/signal_mm.h > delete mode 100644 arch/m68k/include/asm/signal_no.h > delete mode 100644 arch/m68k/include/asm/swab_mm.h > delete mode 100644 arch/m68k/include/asm/swab_no.h > delete mode 100644 arch/m68k/include/asm/unistd_mm.h > delete mode 100644 arch/m68k/include/asm/unistd_no.h > > > I have only patched those files that I saw mentioned in the previous > emails in this thread. > > Geert, can you check an m68k build? > Rob, can you check that you can build what you used to be able to? Nope. Pulled the repository, tarred it up, stuck it in my build system, and the uClibc build still dies attempting to generate syscalls: GEN include/bits/sysnum.h In file included from <stdin>:1: /home/landley/firmware/firmware/build/cross-compiler- m68k/include/asm/unistd.h:4:23: error: unistd_mm.h: No such file or directory In file included from <stdin>:1: /home/landley/firmware/firmware/build/cross-compiler- m68k/include/asm/unistd.h:4:23: error: unistd_mm.h: No such file or directory ERROR: Could not generate syscalls. Rob ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <200903161521.00036.rob@landley.net>]
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7. [not found] ` <200903161521.00036.rob@landley.net> @ 2009-03-16 22:08 ` Geert Uytterhoeven 2009-03-16 23:09 ` Greg Ungerer 2009-03-16 23:10 ` Greg Ungerer 1 sibling, 1 reply; 12+ messages in thread From: Geert Uytterhoeven @ 2009-03-16 22:08 UTC (permalink / raw) To: Rob Landley Cc: Greg Ungerer, Sam Ravnborg, linux-kernel, dwmw2, linux-next, linux-m68k On Mon, Mar 16, 2009 at 21:20, Rob Landley <rob@landley.net> wrote: > On Monday 16 March 2009 07:40:19 Greg Ungerer wrote: >> Geert Uytterhoeven wrote: >> > On Fri, Mar 13, 2009 at 11:52, Greg Ungerer <gerg@snapgear.com> wrote: >> >> Sam Ravnborg wrote: >> >>> On Fri, Mar 13, 2009 at 09:33:18AM +0100, Geert Uytterhoeven wrote: >> >>>> On Fri, Mar 13, 2009 at 09:25, Sam Ravnborg <sam@ravnborg.org> wrote: >> >>>>> On Fri, Mar 13, 2009 at 05:04:57PM +1000, Greg Ungerer wrote: >> >>>>>> I pretty quick time I can fix up the last couple on the above list. >> >>>>>> But do we want to put all that change into 2.6.29-rc at this point? >> >>>>> >> >>>>> In general we do not want to have headers_check broken in mainline, >> >>>> >> >>>> headers_check is not broken, headers_install is. >> >>>> >> >>>> Hmm, in some sense headers_check _is_ broken, as it doesn't notice >> >>>> headers_install >> >>>> installs headers that refer to other headers that are not installed... >> >>> >> >>> This is what scripts/headers_check are supposed to do - strange. >> >>> >> >>>> Greg, I had a quick look at your signcontext.h and signal.h merge, and >> >>>> the MMU >> >>>> part seems to be OK. >> >>>> >> >>>> However, some of the installed headers still have checks for >> >>>> CONFIG_MMU: >> >>>> >> >>>> param.h:#ifdef CONFIG_MMU >> >>>> sigcontext.h:#ifndef CONFIG_MMU >> >>>> sigcontext.h:#ifdef CONFIG_MMU >> >>>> siginfo.h:#ifdef CONFIG_MMU >> >>>> siginfo.h:#ifdef CONFIG_MMU >> >>>> siginfo.h:#endif /* CONFIG_MMU */ >> >>>> swab.h:#elif defined(CONFIG_MMU) >> >>>> >> >>>> so these have to be added to the generic unifdef-y list (is that >> >>>> include/asm-generic/Kbuild.asm?). >> >> >> >> Hmmm, yes your right. >> >> >> >>> include/asm-generic/Kbuild.asm impacts all architectures so be carefull >> >>> there. >> >>> It looks like some updates to arch/m68k/include/asm/Kbuild is needed, >> >>> and not the generic list of files to export. >> >>> >> >>> Also use og CONFIG_MMU suprises me. >> >>> We used #ifdef __uClinux__ in the non-merged headers to avoid use >> >>> of a CONFIG_* symbol that is not valid outside the kernel namespace. >> >>> So if param.h in m68k uses CONFIG_MMU it is broken. >> >> >> >> I have been trying to use CONFIG_MMU wherever possible (so for non- >> >> exported headers), since that matches what is actually in the code >> >> proper. I am concerned at the longer term use of __uClinux__ for >> >> distinguishing MMU and non-MMU. I plan on switching to use a normal >> >> m68k toolchain soon. And it won't define __uClinux__ on its own. >> >> (I already do this on ARM for example - same toolchain on both >> >> MMU an non-MMU). >> >> >> >> What I have done so far is or the most part a very simple merge >> >> of the files. I know there is room for some improvements in quite a >> >> few of these files. >> >> >> >> The use of CONFIG_MMU in swab.h (is this actually exported to user >> >> space?) is not actually for code that is MMU or non-MMU. It is >> >> actually architecture specific. Most ColdFire parts don't have the >> >> "rolw" instruction. The condition test can be better. Geert, any >> >> ideas on what is more appropriate here? >> > >> > The `rolw' variant is already protected by `#if defined >> > (__mcfisaaplus__) || defined (__mcfisac__)', >> > so I think you can replace the `#elif defined(CONFIG_MMU)' by a plain >> > `#else'. Or are there cases where you don't want to have __arch_swab32 at >> > all? >> >> Not all ColdFire fit into '(__mcfisaaplus__) || defined (__mcfisac__)' >> so #else won't be good enough. Though I suspect it is true that the >> older m68k varients (68328, etc) can do "rolw" - or I am I mistaken on >> that? >> >> >> I can switch back to using __uClinux__ on siginfo.h and sigcontext.h. >> >> If I am not mistaken we can't change these structures without breaking >> >> backwards compatibility? The sigcontext change is particularly ugly :-( >> > >> > Copying the signal experts on linux-m68k... >> > >> >> Similarly for param.h, it looks like a switch back to using >> >> __uClinux__ for now is the only option. >> >> >> >> Now after these fixups should I create a git branch with these header >> >> merges in for inclusion into 2.6.29-rc? To fix the regression we >> >> only need to do the handful of files that Rob listed, right? >> > >> > Yes. >> >> Ok, I have created a git branch for this as: >> >> The following changes since commit >> 5bee17f18b595937e6beafeee5197868a3f74a06: Kyle McMartin (1): >> parisc: sba_iommu: fix build bug when CONFIG_PARISC_AGP=y >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git >> fix-includes >> >> Greg Ungerer (8): >> m68k: merge the non-MMU and MMU versions of param.h >> m68k: merge the non-MMU and MMU versions of swab.h >> m68k: merge the non-MMU and MMU versions of sigcontext.h >> m68k: merge the non-MMU and MMU versions of siginfo.h >> m68k: use MMU version of setup.h for both MMU and non-MMU >> m68k: merge the non-MMU and MMU versions of ptrace.h >> m68k: merge the non-MMU and MMU versions of signal.h >> m68k: use the MMU version of unistd.h for all m68k platforms >> >> arch/m68k/include/asm/param.h | 25 ++- >> arch/m68k/include/asm/param_mm.h | 22 -- >> arch/m68k/include/asm/param_no.h | 22 -- >> arch/m68k/include/asm/ptrace.h | 88 ++++++++- >> arch/m68k/include/asm/ptrace_mm.h | 80 ------- >> arch/m68k/include/asm/ptrace_no.h | 87 -------- >> arch/m68k/include/asm/setup.h | 377 >> ++++++++++++++++++++++++++++++++- >> arch/m68k/include/asm/setup_mm.h | 376 >> -------------------------------- >> arch/m68k/include/asm/setup_no.h | 10 - >> arch/m68k/include/asm/sigcontext.h | 25 ++- >> arch/m68k/include/asm/sigcontext_mm.h | 19 -- >> arch/m68k/include/asm/sigcontext_no.h | 17 -- >> arch/m68k/include/asm/siginfo.h | 95 ++++++++- >> arch/m68k/include/asm/siginfo_mm.h | 92 -------- >> arch/m68k/include/asm/siginfo_no.h | 6 - >> arch/m68k/include/asm/signal.h | 216 ++++++++++++++++++- >> arch/m68k/include/asm/signal_mm.h | 206 ------------------ >> arch/m68k/include/asm/signal_no.h | 159 -------------- >> arch/m68k/include/asm/swab.h | 30 +++- >> arch/m68k/include/asm/swab_mm.h | 16 -- >> arch/m68k/include/asm/swab_no.h | 24 -- >> arch/m68k/include/asm/unistd.h | 377 >> ++++++++++++++++++++++++++++++++- >> arch/m68k/include/asm/unistd_mm.h | 372 >> -------------------------------- >> arch/m68k/include/asm/unistd_no.h | 372 >> -------------------------------- >> 24 files changed, 1206 insertions(+), 1907 deletions(-) >> delete mode 100644 arch/m68k/include/asm/param_mm.h >> delete mode 100644 arch/m68k/include/asm/param_no.h >> delete mode 100644 arch/m68k/include/asm/ptrace_mm.h >> delete mode 100644 arch/m68k/include/asm/ptrace_no.h >> delete mode 100644 arch/m68k/include/asm/setup_mm.h >> delete mode 100644 arch/m68k/include/asm/setup_no.h >> delete mode 100644 arch/m68k/include/asm/sigcontext_mm.h >> delete mode 100644 arch/m68k/include/asm/sigcontext_no.h >> delete mode 100644 arch/m68k/include/asm/siginfo_mm.h >> delete mode 100644 arch/m68k/include/asm/siginfo_no.h >> delete mode 100644 arch/m68k/include/asm/signal_mm.h >> delete mode 100644 arch/m68k/include/asm/signal_no.h >> delete mode 100644 arch/m68k/include/asm/swab_mm.h >> delete mode 100644 arch/m68k/include/asm/swab_no.h >> delete mode 100644 arch/m68k/include/asm/unistd_mm.h >> delete mode 100644 arch/m68k/include/asm/unistd_no.h >> >> >> I have only patched those files that I saw mentioned in the previous >> emails in this thread. >> >> Geert, can you check an m68k build? You introduced a build regression by moving the #include <asm-generic/siginfo.h> to the bottom of arch/m68k/include/asm/siginfo.h. After fixing that (patch below, did gmail webmail preserve the tabs?), atari_defconfig builds and runs on ARAnyM. I'm now building a sun3_defconfig... diff --git a/arch/m68k/include/asm/siginfo.h b/arch/m68k/include/asm/siginfo.h index 9999e7d..f88b4a7 100644 --- a/arch/m68k/include/asm/siginfo.h +++ b/arch/m68k/include/asm/siginfo.h @@ -4,7 +4,11 @@ #ifndef __uClinux__ #define HAVE_ARCH_SIGINFO_T #define HAVE_ARCH_COPY_SIGINFO +#endif + +#include <asm-generic/siginfo.h> +#ifndef __uClinux__ typedef struct siginfo { int si_signo; int si_errno; @@ -89,6 +93,4 @@ static inline void copy_siginfo(struct siginfo *to, struct siginfo *from) #endif /* __KERNEL__ */ #endif /* __uClinux__ */ -#include <asm-generic/siginfo.h> - #endif >> Rob, can you check that you can build what you used to be able to? > > Nope. Pulled the repository, tarred it up, stuck it in my build system, and > the uClibc build still dies attempting to generate syscalls: > > GEN include/bits/sysnum.h > In file included from <stdin>:1: > /home/landley/firmware/firmware/build/cross-compiler- > m68k/include/asm/unistd.h:4:23: error: unistd_mm.h: No such file or directory > In file included from <stdin>:1: > /home/landley/firmware/firmware/build/cross-compiler- > m68k/include/asm/unistd.h:4:23: error: unistd_mm.h: No such file or directory > ERROR: Could not generate syscalls. I guess you forgot to check out branch fix-includes? There's no unistd_mm.h in that branch. -- Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7. 2009-03-16 22:08 ` Geert Uytterhoeven @ 2009-03-16 23:09 ` Greg Ungerer 0 siblings, 0 replies; 12+ messages in thread From: Greg Ungerer @ 2009-03-16 23:09 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Rob Landley, Sam Ravnborg, linux-kernel, dwmw2, linux-next, linux-m68k Hi Geert, Geert Uytterhoeven wrote: > On Mon, Mar 16, 2009 at 21:20, Rob Landley <rob@landley.net> wrote: >> On Monday 16 March 2009 07:40:19 Greg Ungerer wrote: >>> Geert Uytterhoeven wrote: >>>> On Fri, Mar 13, 2009 at 11:52, Greg Ungerer <gerg@snapgear.com> wrote: >>>>> Sam Ravnborg wrote: >>>>>> On Fri, Mar 13, 2009 at 09:33:18AM +0100, Geert Uytterhoeven wrote: >>>>>>> On Fri, Mar 13, 2009 at 09:25, Sam Ravnborg <sam@ravnborg.org> wrote: >>>>>>>> On Fri, Mar 13, 2009 at 05:04:57PM +1000, Greg Ungerer wrote: >>>>>>>>> I pretty quick time I can fix up the last couple on the above list. >>>>>>>>> But do we want to put all that change into 2.6.29-rc at this point? >>>>>>>> In general we do not want to have headers_check broken in mainline, >>>>>>> headers_check is not broken, headers_install is. >>>>>>> >>>>>>> Hmm, in some sense headers_check _is_ broken, as it doesn't notice >>>>>>> headers_install >>>>>>> installs headers that refer to other headers that are not installed... >>>>>> This is what scripts/headers_check are supposed to do - strange. >>>>>> >>>>>>> Greg, I had a quick look at your signcontext.h and signal.h merge, and >>>>>>> the MMU >>>>>>> part seems to be OK. >>>>>>> >>>>>>> However, some of the installed headers still have checks for >>>>>>> CONFIG_MMU: >>>>>>> >>>>>>> param.h:#ifdef CONFIG_MMU >>>>>>> sigcontext.h:#ifndef CONFIG_MMU >>>>>>> sigcontext.h:#ifdef CONFIG_MMU >>>>>>> siginfo.h:#ifdef CONFIG_MMU >>>>>>> siginfo.h:#ifdef CONFIG_MMU >>>>>>> siginfo.h:#endif /* CONFIG_MMU */ >>>>>>> swab.h:#elif defined(CONFIG_MMU) >>>>>>> >>>>>>> so these have to be added to the generic unifdef-y list (is that >>>>>>> include/asm-generic/Kbuild.asm?). >>>>> Hmmm, yes your right. >>>>> >>>>>> include/asm-generic/Kbuild.asm impacts all architectures so be carefull >>>>>> there. >>>>>> It looks like some updates to arch/m68k/include/asm/Kbuild is needed, >>>>>> and not the generic list of files to export. >>>>>> >>>>>> Also use og CONFIG_MMU suprises me. >>>>>> We used #ifdef __uClinux__ in the non-merged headers to avoid use >>>>>> of a CONFIG_* symbol that is not valid outside the kernel namespace. >>>>>> So if param.h in m68k uses CONFIG_MMU it is broken. >>>>> I have been trying to use CONFIG_MMU wherever possible (so for non- >>>>> exported headers), since that matches what is actually in the code >>>>> proper. I am concerned at the longer term use of __uClinux__ for >>>>> distinguishing MMU and non-MMU. I plan on switching to use a normal >>>>> m68k toolchain soon. And it won't define __uClinux__ on its own. >>>>> (I already do this on ARM for example - same toolchain on both >>>>> MMU an non-MMU). >>>>> >>>>> What I have done so far is or the most part a very simple merge >>>>> of the files. I know there is room for some improvements in quite a >>>>> few of these files. >>>>> >>>>> The use of CONFIG_MMU in swab.h (is this actually exported to user >>>>> space?) is not actually for code that is MMU or non-MMU. It is >>>>> actually architecture specific. Most ColdFire parts don't have the >>>>> "rolw" instruction. The condition test can be better. Geert, any >>>>> ideas on what is more appropriate here? >>>> The `rolw' variant is already protected by `#if defined >>>> (__mcfisaaplus__) || defined (__mcfisac__)', >>>> so I think you can replace the `#elif defined(CONFIG_MMU)' by a plain >>>> `#else'. Or are there cases where you don't want to have __arch_swab32 at >>>> all? >>> Not all ColdFire fit into '(__mcfisaaplus__) || defined (__mcfisac__)' >>> so #else won't be good enough. Though I suspect it is true that the >>> older m68k varients (68328, etc) can do "rolw" - or I am I mistaken on >>> that? >>> >>>>> I can switch back to using __uClinux__ on siginfo.h and sigcontext.h. >>>>> If I am not mistaken we can't change these structures without breaking >>>>> backwards compatibility? The sigcontext change is particularly ugly :-( >>>> Copying the signal experts on linux-m68k... >>>> >>>>> Similarly for param.h, it looks like a switch back to using >>>>> __uClinux__ for now is the only option. >>>>> >>>>> Now after these fixups should I create a git branch with these header >>>>> merges in for inclusion into 2.6.29-rc? To fix the regression we >>>>> only need to do the handful of files that Rob listed, right? >>>> Yes. >>> Ok, I have created a git branch for this as: >>> >>> The following changes since commit >>> 5bee17f18b595937e6beafeee5197868a3f74a06: Kyle McMartin (1): >>> parisc: sba_iommu: fix build bug when CONFIG_PARISC_AGP=y >>> >>> are available in the git repository at: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git >>> fix-includes >>> >>> Greg Ungerer (8): >>> m68k: merge the non-MMU and MMU versions of param.h >>> m68k: merge the non-MMU and MMU versions of swab.h >>> m68k: merge the non-MMU and MMU versions of sigcontext.h >>> m68k: merge the non-MMU and MMU versions of siginfo.h >>> m68k: use MMU version of setup.h for both MMU and non-MMU >>> m68k: merge the non-MMU and MMU versions of ptrace.h >>> m68k: merge the non-MMU and MMU versions of signal.h >>> m68k: use the MMU version of unistd.h for all m68k platforms >>> >>> arch/m68k/include/asm/param.h | 25 ++- >>> arch/m68k/include/asm/param_mm.h | 22 -- >>> arch/m68k/include/asm/param_no.h | 22 -- >>> arch/m68k/include/asm/ptrace.h | 88 ++++++++- >>> arch/m68k/include/asm/ptrace_mm.h | 80 ------- >>> arch/m68k/include/asm/ptrace_no.h | 87 -------- >>> arch/m68k/include/asm/setup.h | 377 >>> ++++++++++++++++++++++++++++++++- >>> arch/m68k/include/asm/setup_mm.h | 376 >>> -------------------------------- >>> arch/m68k/include/asm/setup_no.h | 10 - >>> arch/m68k/include/asm/sigcontext.h | 25 ++- >>> arch/m68k/include/asm/sigcontext_mm.h | 19 -- >>> arch/m68k/include/asm/sigcontext_no.h | 17 -- >>> arch/m68k/include/asm/siginfo.h | 95 ++++++++- >>> arch/m68k/include/asm/siginfo_mm.h | 92 -------- >>> arch/m68k/include/asm/siginfo_no.h | 6 - >>> arch/m68k/include/asm/signal.h | 216 ++++++++++++++++++- >>> arch/m68k/include/asm/signal_mm.h | 206 ------------------ >>> arch/m68k/include/asm/signal_no.h | 159 -------------- >>> arch/m68k/include/asm/swab.h | 30 +++- >>> arch/m68k/include/asm/swab_mm.h | 16 -- >>> arch/m68k/include/asm/swab_no.h | 24 -- >>> arch/m68k/include/asm/unistd.h | 377 >>> ++++++++++++++++++++++++++++++++- >>> arch/m68k/include/asm/unistd_mm.h | 372 >>> -------------------------------- >>> arch/m68k/include/asm/unistd_no.h | 372 >>> -------------------------------- >>> 24 files changed, 1206 insertions(+), 1907 deletions(-) >>> delete mode 100644 arch/m68k/include/asm/param_mm.h >>> delete mode 100644 arch/m68k/include/asm/param_no.h >>> delete mode 100644 arch/m68k/include/asm/ptrace_mm.h >>> delete mode 100644 arch/m68k/include/asm/ptrace_no.h >>> delete mode 100644 arch/m68k/include/asm/setup_mm.h >>> delete mode 100644 arch/m68k/include/asm/setup_no.h >>> delete mode 100644 arch/m68k/include/asm/sigcontext_mm.h >>> delete mode 100644 arch/m68k/include/asm/sigcontext_no.h >>> delete mode 100644 arch/m68k/include/asm/siginfo_mm.h >>> delete mode 100644 arch/m68k/include/asm/siginfo_no.h >>> delete mode 100644 arch/m68k/include/asm/signal_mm.h >>> delete mode 100644 arch/m68k/include/asm/signal_no.h >>> delete mode 100644 arch/m68k/include/asm/swab_mm.h >>> delete mode 100644 arch/m68k/include/asm/swab_no.h >>> delete mode 100644 arch/m68k/include/asm/unistd_mm.h >>> delete mode 100644 arch/m68k/include/asm/unistd_no.h >>> >>> >>> I have only patched those files that I saw mentioned in the previous >>> emails in this thread. >>> >>> Geert, can you check an m68k build? > > You introduced a build regression by moving the #include <asm-generic/siginfo.h> > to the bottom of arch/m68k/include/asm/siginfo.h. Ah, yes, I was worried that might be the case with that change. I refactored it back to the way it was originally (like your patch). Updated the git tree with that. Thanks Greg > After fixing that (patch below, did gmail webmail preserve the tabs?), > atari_defconfig builds > and runs on ARAnyM. I'm now building a sun3_defconfig... > > diff --git a/arch/m68k/include/asm/siginfo.h b/arch/m68k/include/asm/siginfo.h > index 9999e7d..f88b4a7 100644 > --- a/arch/m68k/include/asm/siginfo.h > +++ b/arch/m68k/include/asm/siginfo.h > @@ -4,7 +4,11 @@ > #ifndef __uClinux__ > #define HAVE_ARCH_SIGINFO_T > #define HAVE_ARCH_COPY_SIGINFO > +#endif > + > +#include <asm-generic/siginfo.h> > > +#ifndef __uClinux__ > typedef struct siginfo { > int si_signo; > int si_errno; > @@ -89,6 +93,4 @@ static inline void copy_siginfo(struct siginfo *to, > struct siginfo *from) > #endif /* __KERNEL__ */ > #endif /* __uClinux__ */ > > -#include <asm-generic/siginfo.h> > - > #endif > >>> Rob, can you check that you can build what you used to be able to? >> Nope. Pulled the repository, tarred it up, stuck it in my build system, and >> the uClibc build still dies attempting to generate syscalls: >> >> GEN include/bits/sysnum.h >> In file included from <stdin>:1: >> /home/landley/firmware/firmware/build/cross-compiler- >> m68k/include/asm/unistd.h:4:23: error: unistd_mm.h: No such file or directory >> In file included from <stdin>:1: >> /home/landley/firmware/firmware/build/cross-compiler- >> m68k/include/asm/unistd.h:4:23: error: unistd_mm.h: No such file or directory >> ERROR: Could not generate syscalls. > > I guess you forgot to check out branch fix-includes? There's no unistd_mm.h in > that branch. > -- ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7. [not found] ` <200903161521.00036.rob@landley.net> 2009-03-16 22:08 ` Geert Uytterhoeven @ 2009-03-16 23:10 ` Greg Ungerer 2009-03-18 4:03 ` Rob Landley 1 sibling, 1 reply; 12+ messages in thread From: Greg Ungerer @ 2009-03-16 23:10 UTC (permalink / raw) To: Rob Landley Cc: Geert Uytterhoeven, Sam Ravnborg, linux-kernel, dwmw2, linux-next, linux-m68k Hi Rob, Rob Landley wrote: > On Monday 16 March 2009 07:40:19 Greg Ungerer wrote: >> Geert Uytterhoeven wrote: >>> On Fri, Mar 13, 2009 at 11:52, Greg Ungerer <gerg@snapgear.com> wrote: >>>> Sam Ravnborg wrote: >>>>> On Fri, Mar 13, 2009 at 09:33:18AM +0100, Geert Uytterhoeven wrote: >>>>>> On Fri, Mar 13, 2009 at 09:25, Sam Ravnborg <sam@ravnborg.org> wrote: >>>>>>> On Fri, Mar 13, 2009 at 05:04:57PM +1000, Greg Ungerer wrote: >>>>>>>> I pretty quick time I can fix up the last couple on the above list. >>>>>>>> But do we want to put all that change into 2.6.29-rc at this point? >>>>>>> In general we do not want to have headers_check broken in mainline, >>>>>> headers_check is not broken, headers_install is. >>>>>> >>>>>> Hmm, in some sense headers_check _is_ broken, as it doesn't notice >>>>>> headers_install >>>>>> installs headers that refer to other headers that are not installed... >>>>> This is what scripts/headers_check are supposed to do - strange. >>>>> >>>>>> Greg, I had a quick look at your signcontext.h and signal.h merge, and >>>>>> the MMU >>>>>> part seems to be OK. >>>>>> >>>>>> However, some of the installed headers still have checks for >>>>>> CONFIG_MMU: >>>>>> >>>>>> param.h:#ifdef CONFIG_MMU >>>>>> sigcontext.h:#ifndef CONFIG_MMU >>>>>> sigcontext.h:#ifdef CONFIG_MMU >>>>>> siginfo.h:#ifdef CONFIG_MMU >>>>>> siginfo.h:#ifdef CONFIG_MMU >>>>>> siginfo.h:#endif /* CONFIG_MMU */ >>>>>> swab.h:#elif defined(CONFIG_MMU) >>>>>> >>>>>> so these have to be added to the generic unifdef-y list (is that >>>>>> include/asm-generic/Kbuild.asm?). >>>> Hmmm, yes your right. >>>> >>>>> include/asm-generic/Kbuild.asm impacts all architectures so be carefull >>>>> there. >>>>> It looks like some updates to arch/m68k/include/asm/Kbuild is needed, >>>>> and not the generic list of files to export. >>>>> >>>>> Also use og CONFIG_MMU suprises me. >>>>> We used #ifdef __uClinux__ in the non-merged headers to avoid use >>>>> of a CONFIG_* symbol that is not valid outside the kernel namespace. >>>>> So if param.h in m68k uses CONFIG_MMU it is broken. >>>> I have been trying to use CONFIG_MMU wherever possible (so for non- >>>> exported headers), since that matches what is actually in the code >>>> proper. I am concerned at the longer term use of __uClinux__ for >>>> distinguishing MMU and non-MMU. I plan on switching to use a normal >>>> m68k toolchain soon. And it won't define __uClinux__ on its own. >>>> (I already do this on ARM for example - same toolchain on both >>>> MMU an non-MMU). >>>> >>>> What I have done so far is or the most part a very simple merge >>>> of the files. I know there is room for some improvements in quite a >>>> few of these files. >>>> >>>> The use of CONFIG_MMU in swab.h (is this actually exported to user >>>> space?) is not actually for code that is MMU or non-MMU. It is >>>> actually architecture specific. Most ColdFire parts don't have the >>>> "rolw" instruction. The condition test can be better. Geert, any >>>> ideas on what is more appropriate here? >>> The `rolw' variant is already protected by `#if defined >>> (__mcfisaaplus__) || defined (__mcfisac__)', >>> so I think you can replace the `#elif defined(CONFIG_MMU)' by a plain >>> `#else'. Or are there cases where you don't want to have __arch_swab32 at >>> all? >> Not all ColdFire fit into '(__mcfisaaplus__) || defined (__mcfisac__)' >> so #else won't be good enough. Though I suspect it is true that the >> older m68k varients (68328, etc) can do "rolw" - or I am I mistaken on >> that? >> >>>> I can switch back to using __uClinux__ on siginfo.h and sigcontext.h. >>>> If I am not mistaken we can't change these structures without breaking >>>> backwards compatibility? The sigcontext change is particularly ugly :-( >>> Copying the signal experts on linux-m68k... >>> >>>> Similarly for param.h, it looks like a switch back to using >>>> __uClinux__ for now is the only option. >>>> >>>> Now after these fixups should I create a git branch with these header >>>> merges in for inclusion into 2.6.29-rc? To fix the regression we >>>> only need to do the handful of files that Rob listed, right? >>> Yes. >> Ok, I have created a git branch for this as: >> >> The following changes since commit >> 5bee17f18b595937e6beafeee5197868a3f74a06: Kyle McMartin (1): >> parisc: sba_iommu: fix build bug when CONFIG_PARISC_AGP=y >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git >> fix-includes >> >> Greg Ungerer (8): >> m68k: merge the non-MMU and MMU versions of param.h >> m68k: merge the non-MMU and MMU versions of swab.h >> m68k: merge the non-MMU and MMU versions of sigcontext.h >> m68k: merge the non-MMU and MMU versions of siginfo.h >> m68k: use MMU version of setup.h for both MMU and non-MMU >> m68k: merge the non-MMU and MMU versions of ptrace.h >> m68k: merge the non-MMU and MMU versions of signal.h >> m68k: use the MMU version of unistd.h for all m68k platforms >> >> arch/m68k/include/asm/param.h | 25 ++- >> arch/m68k/include/asm/param_mm.h | 22 -- >> arch/m68k/include/asm/param_no.h | 22 -- >> arch/m68k/include/asm/ptrace.h | 88 ++++++++- >> arch/m68k/include/asm/ptrace_mm.h | 80 ------- >> arch/m68k/include/asm/ptrace_no.h | 87 -------- >> arch/m68k/include/asm/setup.h | 377 >> ++++++++++++++++++++++++++++++++- >> arch/m68k/include/asm/setup_mm.h | 376 >> -------------------------------- >> arch/m68k/include/asm/setup_no.h | 10 - >> arch/m68k/include/asm/sigcontext.h | 25 ++- >> arch/m68k/include/asm/sigcontext_mm.h | 19 -- >> arch/m68k/include/asm/sigcontext_no.h | 17 -- >> arch/m68k/include/asm/siginfo.h | 95 ++++++++- >> arch/m68k/include/asm/siginfo_mm.h | 92 -------- >> arch/m68k/include/asm/siginfo_no.h | 6 - >> arch/m68k/include/asm/signal.h | 216 ++++++++++++++++++- >> arch/m68k/include/asm/signal_mm.h | 206 ------------------ >> arch/m68k/include/asm/signal_no.h | 159 -------------- >> arch/m68k/include/asm/swab.h | 30 +++- >> arch/m68k/include/asm/swab_mm.h | 16 -- >> arch/m68k/include/asm/swab_no.h | 24 -- >> arch/m68k/include/asm/unistd.h | 377 >> ++++++++++++++++++++++++++++++++- >> arch/m68k/include/asm/unistd_mm.h | 372 >> -------------------------------- >> arch/m68k/include/asm/unistd_no.h | 372 >> -------------------------------- >> 24 files changed, 1206 insertions(+), 1907 deletions(-) >> delete mode 100644 arch/m68k/include/asm/param_mm.h >> delete mode 100644 arch/m68k/include/asm/param_no.h >> delete mode 100644 arch/m68k/include/asm/ptrace_mm.h >> delete mode 100644 arch/m68k/include/asm/ptrace_no.h >> delete mode 100644 arch/m68k/include/asm/setup_mm.h >> delete mode 100644 arch/m68k/include/asm/setup_no.h >> delete mode 100644 arch/m68k/include/asm/sigcontext_mm.h >> delete mode 100644 arch/m68k/include/asm/sigcontext_no.h >> delete mode 100644 arch/m68k/include/asm/siginfo_mm.h >> delete mode 100644 arch/m68k/include/asm/siginfo_no.h >> delete mode 100644 arch/m68k/include/asm/signal_mm.h >> delete mode 100644 arch/m68k/include/asm/signal_no.h >> delete mode 100644 arch/m68k/include/asm/swab_mm.h >> delete mode 100644 arch/m68k/include/asm/swab_no.h >> delete mode 100644 arch/m68k/include/asm/unistd_mm.h >> delete mode 100644 arch/m68k/include/asm/unistd_no.h >> >> >> I have only patched those files that I saw mentioned in the previous >> emails in this thread. >> >> Geert, can you check an m68k build? >> Rob, can you check that you can build what you used to be able to? > > Nope. Pulled the repository, tarred it up, stuck it in my build system, and > the uClibc build still dies attempting to generate syscalls: > > GEN include/bits/sysnum.h > In file included from <stdin>:1: > /home/landley/firmware/firmware/build/cross-compiler- > m68k/include/asm/unistd.h:4:23: error: unistd_mm.h: No such file or directory > In file included from <stdin>:1: > /home/landley/firmware/firmware/build/cross-compiler- > m68k/include/asm/unistd.h:4:23: error: unistd_mm.h: No such file or directory > ERROR: Could not generate syscalls. Did you get the "fix-includes" branch? There is no reference to unistd_mm.h in that branch... Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7. 2009-03-16 23:10 ` Greg Ungerer @ 2009-03-18 4:03 ` Rob Landley 2009-03-18 5:34 ` Greg Ungerer [not found] ` <49C087F3.3080507@snapgear.com> 0 siblings, 2 replies; 12+ messages in thread From: Rob Landley @ 2009-03-18 4:03 UTC (permalink / raw) To: Greg Ungerer Cc: Geert Uytterhoeven, Sam Ravnborg, linux-kernel, dwmw2, linux-next, linux-m68k On Monday 16 March 2009 18:10:45 Greg Ungerer wrote: > >> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git > >> fix-includes ... > Did you get the "fix-includes" branch? Quite possibly not. (I'm not a git person.) I did a "git clone git://blah fix-includes" of the branch you gave a URL to, checked for tags and saw nothing particularly interesting, did a log -v and exported an archive of the most recent commit, and built it. (Just tried it again with the same result.) What _should_ I have done? Rob ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7. 2009-03-18 4:03 ` Rob Landley @ 2009-03-18 5:34 ` Greg Ungerer [not found] ` <49C087F3.3080507@snapgear.com> 1 sibling, 0 replies; 12+ messages in thread From: Greg Ungerer @ 2009-03-18 5:34 UTC (permalink / raw) To: Rob Landley Cc: Geert Uytterhoeven, Sam Ravnborg, linux-kernel, dwmw2, linux-next, linux-m68k Hi Rob, Rob Landley wrote: > On Monday 16 March 2009 18:10:45 Greg Ungerer wrote: >>>> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git >>>> fix-includes > ... >> Did you get the "fix-includes" branch? > > Quite possibly not. (I'm not a git person.) > > I did a "git clone git://blah fix-includes" of the branch you gave a URL to, > checked for tags and saw nothing particularly interesting, did a log -v and > exported an archive of the most recent commit, and built it. > > (Just tried it again with the same result.) > > What _should_ I have done? The git clone you have done will just get the master branch, and put it in a directory named fix-includes. Which is ok, but you still won't have the "fix-includes" branch. Do this after the clone: git pull git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git fix-includes Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <49C087F3.3080507@snapgear.com>]
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7. [not found] ` <49C087F3.3080507@snapgear.com> @ 2009-03-18 18:12 ` Rob Landley [not found] ` <200903181312.02047.rob@landley.net> 1 sibling, 0 replies; 12+ messages in thread From: Rob Landley @ 2009-03-18 18:12 UTC (permalink / raw) To: Greg Ungerer Cc: Geert Uytterhoeven, Sam Ravnborg, linux-kernel, dwmw2, linux-next, linux-m68k On Wednesday 18 March 2009 00:34:43 Greg Ungerer wrote: > Hi Rob, > > Rob Landley wrote: > > On Monday 16 March 2009 18:10:45 Greg Ungerer wrote: > >>>> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git > >>>> fix-includes ... > > What _should_ I have done? > > The git clone you have done will just get the master branch, > and put it in a directory named fix-includes. > > Which is ok, but you still won't have the "fix-includes" branch. > Do this after the clone: > > git pull > git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git > fix-includes Ah, that did something interesting... And the resulting headers built in uClibc. (Works for me!) confirmed-uClibc-builds-with-it-by: Rob Landley <rob@landley.net> Thanks, Rob ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <200903181312.02047.rob@landley.net>]
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7. [not found] ` <200903181312.02047.rob@landley.net> @ 2009-03-18 23:53 ` Greg Ungerer 2009-03-19 7:59 ` Geert Uytterhoeven 1 sibling, 0 replies; 12+ messages in thread From: Greg Ungerer @ 2009-03-18 23:53 UTC (permalink / raw) To: Rob Landley Cc: Geert Uytterhoeven, Sam Ravnborg, linux-kernel, dwmw2, linux-next, linux-m68k Hi Rob, Rob Landley wrote: > On Wednesday 18 March 2009 00:34:43 Greg Ungerer wrote: >> Hi Rob, >> >> Rob Landley wrote: >>> On Monday 16 March 2009 18:10:45 Greg Ungerer wrote: >>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git >>>>>> fix-includes > ... >>> What _should_ I have done? >> The git clone you have done will just get the master branch, >> and put it in a directory named fix-includes. >> >> Which is ok, but you still won't have the "fix-includes" branch. >> Do this after the clone: >> >> git pull >> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git >> fix-includes > > Ah, that did something interesting... And the resulting headers built in > uClibc. (Works for me!) > > confirmed-uClibc-builds-with-it-by: Rob Landley <rob@landley.net> Thats great, thanks. I'll push to Linus then. Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7. [not found] ` <200903181312.02047.rob@landley.net> 2009-03-18 23:53 ` Greg Ungerer @ 2009-03-19 7:59 ` Geert Uytterhoeven 2009-03-19 8:41 ` Rob Landley 1 sibling, 1 reply; 12+ messages in thread From: Geert Uytterhoeven @ 2009-03-19 7:59 UTC (permalink / raw) To: Rob Landley Cc: Greg Ungerer, Sam Ravnborg, linux-kernel, dwmw2, linux-next, linux-m68k On Wed, Mar 18, 2009 at 19:12, Rob Landley <rob@landley.net> wrote: > On Wednesday 18 March 2009 00:34:43 Greg Ungerer wrote: >> Rob Landley wrote: >> > On Monday 16 March 2009 18:10:45 Greg Ungerer wrote: >> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git >> >>>> fix-includes > ... >> > What _should_ I have done? >> >> The git clone you have done will just get the master branch, >> and put it in a directory named fix-includes. >> >> Which is ok, but you still won't have the "fix-includes" branch. >> Do this after the clone: >> >> git pull >> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git >> fix-includes > > Ah, that did something interesting... And the resulting headers built in > uClibc. (Works for me!) > > confirmed-uClibc-builds-with-it-by: Rob Landley <rob@landley.net> Does it boot on ARAnyM? ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7. 2009-03-19 7:59 ` Geert Uytterhoeven @ 2009-03-19 8:41 ` Rob Landley 0 siblings, 0 replies; 12+ messages in thread From: Rob Landley @ 2009-03-19 8:41 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Greg Ungerer, Sam Ravnborg, linux-kernel, dwmw2, linux-next, linux-m68k On Thursday 19 March 2009 02:59:45 Geert Uytterhoeven wrote: > On Wed, Mar 18, 2009 at 19:12, Rob Landley <rob@landley.net> wrote: > > On Wednesday 18 March 2009 00:34:43 Greg Ungerer wrote: > >> Rob Landley wrote: > >> > On Monday 16 March 2009 18:10:45 Greg Ungerer wrote: > >> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git > >> >>>> fix-includes > > > > ... > > > >> > What _should_ I have done? > >> > >> The git clone you have done will just get the master branch, > >> and put it in a directory named fix-includes. > >> > >> Which is ok, but you still won't have the "fix-includes" branch. > >> Do this after the clone: > >> > >> git pull > >> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git > >> fix-includes > > > > Ah, that did something interesting... And the resulting headers built in > > uClibc. (Works for me!) > > > > confirmed-uClibc-builds-with-it-by: Rob Landley <rob@landley.net> > > Does it boot on ARAnyM? ;-) Dunno. When I ran aranym it popped up a menu screen and asked me to configure it, so I tracked down a couple of howtos I haven't had time to read yet (http://wiki.aranym.org/aranym_from_scratch and http://wiki.aranym.org/afs/setup_linux). At a glance the emulator doesn't seem to actually support a serial port, so no serial console, which is a bit of a limiting factor for how I normally use it... Rob ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-03-19 8:41 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200903120437.03837.rob@landley.net>
[not found] ` <20090312210216.GB14205@uranus.ravnborg.org>
[not found] ` <10f740e80903121540i30fdaddr600ce21f4159530a@mail.gmail.com>
[not found] ` <200903122225.04560.rob@landley.net>
[not found] ` <49BA0599.6070206@snapgear.com>
[not found] ` <20090313082555.GA19045@uranus.ravnborg.org>
[not found] ` <10f740e80903130133r130b8713v690437f0f38eb0b8@mail.gmail.com>
[not found] ` <20090313085930.GA19274@uranus.ravnborg.org>
[not found] ` <49BA3B05.9020906@snapgear.com>
2009-03-13 12:14 ` make headers_install broken for ARCH=m68k in 2.6.29-rc7 Geert Uytterhoeven
2009-03-16 12:40 ` Greg Ungerer
[not found] ` <49BE48B3.6060108@snapgear.com>
2009-03-16 20:20 ` Rob Landley
[not found] ` <200903161521.00036.rob@landley.net>
2009-03-16 22:08 ` Geert Uytterhoeven
2009-03-16 23:09 ` Greg Ungerer
2009-03-16 23:10 ` Greg Ungerer
2009-03-18 4:03 ` Rob Landley
2009-03-18 5:34 ` Greg Ungerer
[not found] ` <49C087F3.3080507@snapgear.com>
2009-03-18 18:12 ` Rob Landley
[not found] ` <200903181312.02047.rob@landley.net>
2009-03-18 23:53 ` Greg Ungerer
2009-03-19 7:59 ` Geert Uytterhoeven
2009-03-19 8:41 ` Rob Landley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox