On Fri, Mar 13, 2009 at 11:52, Greg Ungerer <gerg@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
