* make headers_install broken for ARCH=m68k in 2.6.29-rc7.
@ 2009-03-12 9:37 Rob Landley
2009-03-12 9:58 ` Sam Ravnborg
2009-04-01 16:57 ` Lennart Sorensen
0 siblings, 2 replies; 50+ messages in thread
From: Rob Landley @ 2009-03-12 9:37 UTC (permalink / raw)
To: linux-kernel; +Cc: dwmw2
So I'm doing this:
make ARCH=m68k headers_install INSTALL_HDR_PATH=walrus
And it doesn't install unistd_mm.h which is included from asm/unistd.h. (The
file is there in arch/m68k/include/asm/unistd_mm.h, it just doesn't get
installed. So any code that #includes <asm/unistd.h> results in a file not
found error for the other one, which is essentially just a wrapper.)
I don't understand what the code's currently doing here well enough to fix it,
specifically where does this file list come from? The file
arch/m68k/include/asm/Kbuild is adding "cachectl.h" to header-y, but there are
31 files getting installed from that directory and only one in there. If the
list was just the contents of the directory, then unistd_mm.h (and
unistd_no.h) would get installed, but they don't. I could add those two to
the Kbuild file after cachectl.h, but is that the _right_ fix? Where are the
other 31 identified? (Is it getting a listing of some _other_ directory?)
Confused,
Rob
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-12 9:37 make headers_install broken for ARCH=m68k in 2.6.29-rc7 Rob Landley
@ 2009-03-12 9:58 ` Sam Ravnborg
2009-03-12 20:03 ` Rob Landley
2009-04-01 16:57 ` Lennart Sorensen
1 sibling, 1 reply; 50+ messages in thread
From: Sam Ravnborg @ 2009-03-12 9:58 UTC (permalink / raw)
To: Rob Landley; +Cc: linux-kernel, dwmw2
On Thu, Mar 12, 2009 at 04:37:03AM -0500, Rob Landley wrote:
> So I'm doing this:
>
> make ARCH=m68k headers_install INSTALL_HDR_PATH=walrus
>
> And it doesn't install unistd_mm.h which is included from asm/unistd.h. (The
> file is there in arch/m68k/include/asm/unistd_mm.h, it just doesn't get
> installed. So any code that #includes <asm/unistd.h> results in a file not
> found error for the other one, which is essentially just a wrapper.)
>
> I don't understand what the code's currently doing here well enough to fix it,
> specifically where does this file list come from? The file
> arch/m68k/include/asm/Kbuild is adding "cachectl.h" to header-y, but there are
> 31 files getting installed from that directory and only one in there.
Kbuild contains the following:
include include/asm-generic/Kbuild.asm
header-y += cachectl.h
And if you look up the content of "include/asm-generic/Kbuild.asm"
you will realize that this is a list of all the "always to be exported headers"
from any arch - so the list is consolidated in asm-generic.
The fix for m68k is to eiter:
1) unify unistd.h so we get rid of the _no.h and _mm.h variants
2) or add the _no.h and _mm.h files to Kbuild.
I recall that someone already did 1) and this is pending in m68k.git.
You could look in -next - I think it is fixed there.
Sam
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-12 9:58 ` Sam Ravnborg
@ 2009-03-12 20:03 ` Rob Landley
2009-03-12 20:58 ` Sam Ravnborg
2009-03-12 21:02 ` Sam Ravnborg
0 siblings, 2 replies; 50+ messages in thread
From: Rob Landley @ 2009-03-12 20:03 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-kernel, dwmw2, linux-next
On Thursday 12 March 2009 04:58:54 Sam Ravnborg wrote:
> On Thu, Mar 12, 2009 at 04:37:03AM -0500, Rob Landley wrote:
> > So I'm doing this:
> >
> > make ARCH=m68k headers_install INSTALL_HDR_PATH=walrus
> >
> > And it doesn't install unistd_mm.h which is included from asm/unistd.h.
> > (The file is there in arch/m68k/include/asm/unistd_mm.h, it just doesn't
> > get installed. So any code that #includes <asm/unistd.h> results in a
> > file not found error for the other one, which is essentially just a
> > wrapper.)
> >
> > I don't understand what the code's currently doing here well enough to
> > fix it, specifically where does this file list come from? The file
> > arch/m68k/include/asm/Kbuild is adding "cachectl.h" to header-y, but
> > there are 31 files getting installed from that directory and only one in
> > there.
>
> Kbuild contains the following:
>
> include include/asm-generic/Kbuild.asm
> header-y += cachectl.h
>
> And if you look up the content of "include/asm-generic/Kbuild.asm"
Ah, I was grepping for header-y and this is full of unifdef-y, so I didn't
look too closely at this file. (I did glance at it, but the first thing I saw
was "errno.h" and there's an errno.h in the include/asm-generic directory, so
I thought it was describing itself. I presume it tries the arch one first and
falls back to asm-generic if it's not there?)
> you will realize that this is a list of all the "always to be exported
> headers" from any arch - so the list is consolidated in asm-generic.
>
> The fix for m68k is to eiter:
> 1) unify unistd.h so we get rid of the _no.h and _mm.h variants
> 2) or add the _no.h and _mm.h files to Kbuild.
>
> I recall that someone already did 1) and this is pending in m68k.git.
I hope this patch can be cherry picked so 2.6.29 doesn't ship broken for m68k.
> You could look in -next - I think it is fixed there.
Is there any way to download that as a tarball? No mention of it on the main
kernel.org page. I checked
http://www.kernel.org/pub/linux/kernel/testing/
http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/
http://www.kernel.org/pub/linux/kernel/v2.6/testing/
and a few other places. No dice.
Googling for "linux-next" finds a blog entry and a few links to discussion on
kernel trap, but no link to where to _get_ it in any of those...
Googling for "linux-next tarball" finds... http://lkml.org/lkml/2008/2/21/449
which has a dead link. And by the third google hit we're into discussion of
the 2.4.18 kernel and hppa platform. Not promising.
Seems kind of silly to let git grind away downloading hundreds of megabytes of
history that'll just get wiped (especially since that tree gets regenerated
nightly), but oh well. Assuming that kernel development is git-centric enough
that a tarball version of a regenerated nightly resource just never seemed
important, said git repository would be on git.kernel.org, but where...
linux/kernel/git/eranian/linux-next.git isn't it...
linux/kernel/git/mchehab/linux-next.git isn't it...
Ah, linux/kernel/git/sfr/linux-next.git is the one I'm looking for. Now where
was the magic incantation to translate from the web url to a git url... Ah,
at the top of the page.
time git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
Wander off to read the big long http://lkml.org/lkml/2008/2/11/512 thread
google pulled up earlier, wander back when bored, the download is at 43%
averaging about 350k/second... Go read some more...
Am I doing something wrong here? Other people can't possibly find this A)
this tedious, B) this undocumented.
And it finished:
> real 22m38.058s
> user 2m27.257s
> sys 0m34.258s
And, yes, I can confirm the m68k include/asm/unistd.h from linux-next actually
has contents, thanks to commit 646652bded41f4c3bd375b4e03a25b42da93f40b
Anyway, here's hoping the fix makes it into 2.6.29.
> Sam
Rob
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-12 20:03 ` Rob Landley
@ 2009-03-12 20:58 ` Sam Ravnborg
2009-03-12 23:24 ` Stephen Rothwell
2009-03-12 21:02 ` Sam Ravnborg
1 sibling, 1 reply; 50+ messages in thread
From: Sam Ravnborg @ 2009-03-12 20:58 UTC (permalink / raw)
To: Rob Landley; +Cc: linux-kernel, dwmw2, linux-next
> > And if you look up the content of "include/asm-generic/Kbuild.asm"
>
> Ah, I was grepping for header-y and this is full of unifdef-y, so I didn't
> look too closely at this file. (I did glance at it, but the first thing I saw
> was "errno.h" and there's an errno.h in the include/asm-generic directory, so
> I thought it was describing itself. I presume it tries the arch one first and
> falls back to asm-generic if it's not there?)
No - it uses what it is told to use. Look again.
We have in asm-generic two files:
Kbuild <= what is exported always and located in asm-generic
Kbuild.asm <= exported from archs asm - just a common list of file names
>
>
> Seems kind of silly to let git grind away downloading hundreds of megabytes of
> history that'll just get wiped (especially since that tree gets regenerated
> nightly), but oh well. Assuming that kernel development is git-centric enough
> that a tarball version of a regenerated nightly resource just never seemed
> important, said git repository would be on git.kernel.org, but where...
> linux/kernel/git/eranian/linux-next.git isn't it...
> linux/kernel/git/mchehab/linux-next.git isn't it...
> Ah, linux/kernel/git/sfr/linux-next.git is the one I'm looking for. Now where
> was the magic incantation to translate from the web url to a git url... Ah,
> at the top of the page.
Usual people read the announcement mails from Stephen and follow the instructions there.
And many people keep an updated git tree around speeding up the process.
I cannot remember when I clone a full kernel tree - long time ago for sure.
Sam
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-12 20:03 ` Rob Landley
2009-03-12 20:58 ` Sam Ravnborg
@ 2009-03-12 21:02 ` Sam Ravnborg
2009-03-12 22:40 ` Geert Uytterhoeven
1 sibling, 1 reply; 50+ messages in thread
From: Sam Ravnborg @ 2009-03-12 21:02 UTC (permalink / raw)
To: Rob Landley; +Cc: linux-kernel, dwmw2, linux-next, geert
>
> And, yes, I can confirm the m68k include/asm/unistd.h from linux-next actually
> has contents, thanks to commit 646652bded41f4c3bd375b4e03a25b42da93f40b
>
> Anyway, here's hoping the fix makes it into 2.6.29.
Why not telling the m68k maintainer that you think it should go into 2.6.29?
As it stand now we will ikely see another mail from you "I already said so"
when we ship it broken but you did not care to tell relevant people.
grep -C 5 -i m68k MAINTAINES revelas this:
M68K ARCHITECTURE
P: Geert Uytterhoeven
M: geert@linux-m68k.org
P: Roman Zippel
M: zippel@linux-m68k.org
L: linux-m68k@lists.linux-m68k.org
W: http://www.linux-m68k.org/
W: http://linux-m68k-cvs.ubb.ca/
S: Maintained
Sam
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-12 21:02 ` Sam Ravnborg
@ 2009-03-12 22:40 ` Geert Uytterhoeven
2009-03-13 3:25 ` Rob Landley
2009-03-13 6:53 ` Greg Ungerer
0 siblings, 2 replies; 50+ messages in thread
From: Geert Uytterhoeven @ 2009-03-12 22:40 UTC (permalink / raw)
To: Rob Landley, Sam Ravnborg, Greg Ungerer; +Cc: linux-kernel, dwmw2, linux-next
On Thu, Mar 12, 2009 at 22:02, Sam Ravnborg <sam@ravnborg.org> wrote:
>>
>> And, yes, I can confirm the m68k include/asm/unistd.h from linux-next actually
>> has contents, thanks to commit 646652bded41f4c3bd375b4e03a25b42da93f40b
>>
>> Anyway, here's hoping the fix makes it into 2.6.29.
>
> Why not telling the m68k maintainer that you think it should go into 2.6.29?
>
> As it stand now we will ikely see another mail from you "I already said so"
> when we ship it broken but you did not care to tell relevant people.
>
> grep -C 5 -i m68k MAINTAINES revelas this:
> M68K ARCHITECTURE
> P: Geert Uytterhoeven
> M: geert@linux-m68k.org
> P: Roman Zippel
> M: zippel@linux-m68k.org
> L: linux-m68k@lists.linux-m68k.org
> W: http://www.linux-m68k.org/
> W: http://linux-m68k-cvs.ubb.ca/
> S: Maintained
>
>
> Sam
>
There are a few more:
param.h:#include "param_no.h"
param.h:#include "param_mm.h"
ptrace.h:#include "ptrace_no.h"
ptrace.h:#include "ptrace_mm.h"
setup.h:#include "setup_no.h"
setup.h:#include "setup_mm.h"
sigcontext.h:#include "sigcontext_no.h"
sigcontext.h:#include "sigcontext_mm.h"
siginfo.h:#include "siginfo_no.h"
siginfo.h:#include "siginfo_mm.h"
signal.h:#include "signal_no.h"
signal.h:#include "signal_mm.h"
swab.h:#include "swab_no.h"
swab.h:#include "swab_mm.h"
Rob, do these also causes problems?
Some (not all) of them are fixed in linux-next.
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 [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-12 20:58 ` Sam Ravnborg
@ 2009-03-12 23:24 ` Stephen Rothwell
0 siblings, 0 replies; 50+ messages in thread
From: Stephen Rothwell @ 2009-03-12 23:24 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Rob Landley, linux-kernel, dwmw2, linux-next
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
On Thu, 12 Mar 2009 21:58:26 +0100 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Usual people read the announcement mails from Stephen and follow the instructions there.
> And many people keep an updated git tree around speeding up the process.
And that announcement (on LKML every day) says:
"I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/)."
The patches are releative to Linus' tree. I assume most kernel
developers have access to fairly recent versions of Linus' tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-12 22:40 ` Geert Uytterhoeven
@ 2009-03-13 3:25 ` Rob Landley
2009-03-13 7:04 ` Greg Ungerer
2009-03-13 8:25 ` Geert Uytterhoeven
2009-03-13 6:53 ` Greg Ungerer
1 sibling, 2 replies; 50+ messages in thread
From: Rob Landley @ 2009-03-13 3:25 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sam Ravnborg, Greg Ungerer, linux-kernel, dwmw2, linux-next
On Thursday 12 March 2009 17:40:02 Geert Uytterhoeven wrote:
> On Thu, Mar 12, 2009 at 22:02, Sam Ravnborg <sam@ravnborg.org> wrote:
> >> And, yes, I can confirm the m68k include/asm/unistd.h from linux-next
> >> actually has contents, thanks to commit
> >> 646652bded41f4c3bd375b4e03a25b42da93f40b
> >>
> >> Anyway, here's hoping the fix makes it into 2.6.29.
> >
> > Why not telling the m68k maintainer that you think it should go into
> > 2.6.29?
I contacted the headers_install maintainer about a headers_install problem,
and was pointed to an existing fix upstream. This seemed to imply awareness
of the problem?
Happy to follow up more, wasn't aware it was required...
> There are a few more:
>
> param.h:#include "param_no.h"
> param.h:#include "param_mm.h"
> ptrace.h:#include "ptrace_no.h"
> ptrace.h:#include "ptrace_mm.h"
> setup.h:#include "setup_no.h"
> setup.h:#include "setup_mm.h"
> sigcontext.h:#include "sigcontext_no.h"
> sigcontext.h:#include "sigcontext_mm.h"
> siginfo.h:#include "siginfo_no.h"
> siginfo.h:#include "siginfo_mm.h"
> signal.h:#include "signal_no.h"
> signal.h:#include "signal_mm.h"
> swab.h:#include "swab_no.h"
> swab.h:#include "swab_mm.h"
>
> Rob, do these also causes problems?
> Some (not all) of them are fixed in linux-next.
I'm trying to build uClibc against the new headers. I just got around to
extracting the patch to fix that one file and testing it in my build system,
and this time it broke with:
build/cross-compiler-m68k/include/asm/param.h:4:22: error: param_mm.h: No
such file or directory
So yeah, it's still unhappy. Dunno how many of these are still needed to
build the cross compiler, and then who knows what other packages need to
build. Presumably all of it.
Keep in mind I still haven't found an emulator for m68k that actually boots a
linux kernel, so my m68k support is purely theoretical. (I poked at mess and
uae a bit today, but they don't do the "qemu -kernel" thing I'm using for the
other targets, and qemu itself only seems to support coldfire and not a full-
blown m68k.) I'm following up on this because it's a regression. Under
2.6.28 the m68k target was building a kernel and root filesystem, but I don't
have hardware to run it and have never been able to test it, so isn't really
very useful for me. It's really just there so that if qemu grows the rest of
m68k support (patches have been submitted but not merged), I'll be ready.
P.S. If you're bored and want to try my test build for yourself:
wget http://impactlinux.com/hg/firmware/archive/tip.tar.bz2
tar xvjf tip.tar.bz2
cd firmware-*
USE_UNSTABLE=linux ./build.sh m68k
Without the USE_UNSTABLE=linux it uses 2.6.28 and builds to completion, with
it the build uses 2.6.29-rc7 (or whatever URL's listed as the UNSTABLE= value
for linux in download.sh) and it breaks trying to add uClibc to the cross
compiler.
But then anything that actually _uses_ the "make headers_install" output to
build stuff against should notice pretty quickly whether or not it #includes
missing files.
Rob
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-12 22:40 ` Geert Uytterhoeven
2009-03-13 3:25 ` Rob Landley
@ 2009-03-13 6:53 ` Greg Ungerer
1 sibling, 0 replies; 50+ messages in thread
From: Greg Ungerer @ 2009-03-13 6:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Landley, Sam Ravnborg, linux-kernel, dwmw2, linux-next
Geert Uytterhoeven wrote:
> On Thu, Mar 12, 2009 at 22:02, Sam Ravnborg <sam@ravnborg.org> wrote:
>>> And, yes, I can confirm the m68k include/asm/unistd.h from linux-next actually
>>> has contents, thanks to commit 646652bded41f4c3bd375b4e03a25b42da93f40b
>>>
>>> Anyway, here's hoping the fix makes it into 2.6.29.
>> Why not telling the m68k maintainer that you think it should go into 2.6.29?
>>
>> As it stand now we will ikely see another mail from you "I already said so"
>> when we ship it broken but you did not care to tell relevant people.
>>
>> grep -C 5 -i m68k MAINTAINES revelas this:
>> M68K ARCHITECTURE
>> P: Geert Uytterhoeven
>> M: geert@linux-m68k.org
>> P: Roman Zippel
>> M: zippel@linux-m68k.org
>> L: linux-m68k@lists.linux-m68k.org
>> W: http://www.linux-m68k.org/
>> W: http://linux-m68k-cvs.ubb.ca/
>> S: Maintained
>>
>>
>> Sam
>>
>
> There are a few more:
>
> param.h:#include "param_no.h"
> param.h:#include "param_mm.h"
> ptrace.h:#include "ptrace_no.h"
> ptrace.h:#include "ptrace_mm.h"
> setup.h:#include "setup_no.h"
> setup.h:#include "setup_mm.h"
> sigcontext.h:#include "sigcontext_no.h"
> sigcontext.h:#include "sigcontext_mm.h"
> siginfo.h:#include "siginfo_no.h"
> siginfo.h:#include "siginfo_mm.h"
> signal.h:#include "signal_no.h"
> signal.h:#include "signal_mm.h"
> swab.h:#include "swab_no.h"
> swab.h:#include "swab_mm.h"
>
> Rob, do these also causes problems?
> Some (not all) of them are fixed in linux-next.
My patches in linux-next (from the m68knommu git tree) should
fix all but sigconext and signal in that list.
Both of those are relatively easy to fix up. I'll do that.
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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-13 3:25 ` Rob Landley
@ 2009-03-13 7:04 ` Greg Ungerer
2009-03-13 8:25 ` Sam Ravnborg
2009-03-13 8:25 ` Geert Uytterhoeven
1 sibling, 1 reply; 50+ messages in thread
From: Greg Ungerer @ 2009-03-13 7:04 UTC (permalink / raw)
To: Rob Landley
Cc: Geert Uytterhoeven, Sam Ravnborg, linux-kernel, dwmw2, linux-next
Rob Landley wrote:
> On Thursday 12 March 2009 17:40:02 Geert Uytterhoeven wrote:
>> On Thu, Mar 12, 2009 at 22:02, Sam Ravnborg <sam@ravnborg.org> wrote:
>>>> And, yes, I can confirm the m68k include/asm/unistd.h from linux-next
>>>> actually has contents, thanks to commit
>>>> 646652bded41f4c3bd375b4e03a25b42da93f40b
>>>>
>>>> Anyway, here's hoping the fix makes it into 2.6.29.
>>> Why not telling the m68k maintainer that you think it should go into
>>> 2.6.29?
>
> I contacted the headers_install maintainer about a headers_install problem,
> and was pointed to an existing fix upstream. This seemed to imply awareness
> of the problem?
>
> Happy to follow up more, wasn't aware it was required...
>
>> There are a few more:
>>
>> param.h:#include "param_no.h"
>> param.h:#include "param_mm.h"
>> ptrace.h:#include "ptrace_no.h"
>> ptrace.h:#include "ptrace_mm.h"
>> setup.h:#include "setup_no.h"
>> setup.h:#include "setup_mm.h"
>> sigcontext.h:#include "sigcontext_no.h"
>> sigcontext.h:#include "sigcontext_mm.h"
>> siginfo.h:#include "siginfo_no.h"
>> siginfo.h:#include "siginfo_mm.h"
>> signal.h:#include "signal_no.h"
>> signal.h:#include "signal_mm.h"
>> swab.h:#include "swab_no.h"
>> swab.h:#include "swab_mm.h"
>>
>> Rob, do these also causes problems?
>> Some (not all) of them are fixed in linux-next.
>
> I'm trying to build uClibc against the new headers. I just got around to
> extracting the patch to fix that one file and testing it in my build system,
> and this time it broke with:
>
> build/cross-compiler-m68k/include/asm/param.h:4:22: error: param_mm.h: No
> such file or directory
>
> So yeah, it's still unhappy. Dunno how many of these are still needed to
> build the cross compiler, and then who knows what other packages need to
> build. Presumably all of it.
>
> Keep in mind I still haven't found an emulator for m68k that actually boots a
> linux kernel, so my m68k support is purely theoretical. (I poked at mess and
> uae a bit today, but they don't do the "qemu -kernel" thing I'm using for the
> other targets, and qemu itself only seems to support coldfire and not a full-
> blown m68k.) I'm following up on this because it's a regression. Under
> 2.6.28 the m68k target was building a kernel and root filesystem, but I don't
> have hardware to run it and have never been able to test it, so isn't really
> very useful for me. It's really just there so that if qemu grows the rest of
> m68k support (patches have been submitted but not merged), I'll be ready.
>
> P.S. If you're bored and want to try my test build for yourself:
>
> wget http://impactlinux.com/hg/firmware/archive/tip.tar.bz2
> tar xvjf tip.tar.bz2
> cd firmware-*
> USE_UNSTABLE=linux ./build.sh m68k
>
> Without the USE_UNSTABLE=linux it uses 2.6.28 and builds to completion, with
> it the build uses 2.6.29-rc7 (or whatever URL's listed as the UNSTABLE= value
> for linux in download.sh) and it breaks trying to add uClibc to the cross
> compiler.
>
> But then anything that actually _uses_ the "make headers_install" output to
> build stuff against should notice pretty quickly whether or not it #includes
> missing files.
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?
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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-13 3:25 ` Rob Landley
2009-03-13 7:04 ` Greg Ungerer
@ 2009-03-13 8:25 ` Geert Uytterhoeven
1 sibling, 0 replies; 50+ messages in thread
From: Geert Uytterhoeven @ 2009-03-13 8:25 UTC (permalink / raw)
To: Rob Landley; +Cc: Sam Ravnborg, Greg Ungerer, linux-kernel, dwmw2, linux-next
On Fri, Mar 13, 2009 at 04:25, Rob Landley <rob@landley.net> wrote:
> Keep in mind I still haven't found an emulator for m68k that actually boots a
> linux kernel, so my m68k support is purely theoretical. (I poked at mess and
> uae a bit today, but they don't do the "qemu -kernel" thing I'm using for the
> other targets, and qemu itself only seems to support coldfire and not a full-
> blown m68k.) I'm following up on this because it's a regression. Under
> 2.6.28 the m68k target was building a kernel and root filesystem, but I don't
> have hardware to run it and have never been able to test it, so isn't really
> very useful for me. It's really just there so that if qemu grows the rest of
> m68k support (patches have been submitted but not merged), I'll be ready.
An atari_defconfig kernel (at least the one from Linus-yesterday) boots fine on
aranym (http://aranym.org).
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 [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-13 7:04 ` Greg Ungerer
@ 2009-03-13 8:25 ` Sam Ravnborg
2009-03-13 8:33 ` Geert Uytterhoeven
0 siblings, 1 reply; 50+ messages in thread
From: Sam Ravnborg @ 2009-03-13 8:25 UTC (permalink / raw)
To: Greg Ungerer
Cc: Rob Landley, Geert Uytterhoeven, linux-kernel, dwmw2, linux-next
On Fri, Mar 13, 2009 at 05:04:57PM +1000, Greg Ungerer wrote:
>
> Rob Landley wrote:
> >On Thursday 12 March 2009 17:40:02 Geert Uytterhoeven wrote:
> >>On Thu, Mar 12, 2009 at 22:02, Sam Ravnborg <sam@ravnborg.org> wrote:
> >>>>And, yes, I can confirm the m68k include/asm/unistd.h from linux-next
> >>>>actually has contents, thanks to commit
> >>>>646652bded41f4c3bd375b4e03a25b42da93f40b
> >>>>
> >>>>Anyway, here's hoping the fix makes it into 2.6.29.
> >>>Why not telling the m68k maintainer that you think it should go into
> >>>2.6.29?
> >
> >I contacted the headers_install maintainer about a headers_install
> >problem, and was pointed to an existing fix upstream. This seemed to
> >imply awareness of the problem?
> >
> >Happy to follow up more, wasn't aware it was required...
> >
> >>There are a few more:
> >>
> >>param.h:#include "param_no.h"
> >>param.h:#include "param_mm.h"
> >>ptrace.h:#include "ptrace_no.h"
> >>ptrace.h:#include "ptrace_mm.h"
> >>setup.h:#include "setup_no.h"
> >>setup.h:#include "setup_mm.h"
> >>sigcontext.h:#include "sigcontext_no.h"
> >>sigcontext.h:#include "sigcontext_mm.h"
> >>siginfo.h:#include "siginfo_no.h"
> >>siginfo.h:#include "siginfo_mm.h"
> >>signal.h:#include "signal_no.h"
> >>signal.h:#include "signal_mm.h"
> >>swab.h:#include "swab_no.h"
> >>swab.h:#include "swab_mm.h"
> >>
> >>Rob, do these also causes problems?
> >>Some (not all) of them are fixed in linux-next.
> >
> >I'm trying to build uClibc against the new headers. I just got around to
> >extracting the patch to fix that one file and testing it in my build
> >system, and this time it broke with:
> >
> > build/cross-compiler-m68k/include/asm/param.h:4:22: error: param_mm.h: No
> > such file or directory
> >
> >So yeah, it's still unhappy. Dunno how many of these are still needed to
> >build the cross compiler, and then who knows what other packages need to
> >build. Presumably all of it.
> >
> >Keep in mind I still haven't found an emulator for m68k that actually
> >boots a linux kernel, so my m68k support is purely theoretical. (I poked
> >at mess and uae a bit today, but they don't do the "qemu -kernel" thing
> >I'm using for the other targets, and qemu itself only seems to support
> >coldfire and not a full-
> >blown m68k.) I'm following up on this because it's a regression. Under
> >2.6.28 the m68k target was building a kernel and root filesystem, but I
> >don't have hardware to run it and have never been able to test it, so
> >isn't really very useful for me. It's really just there so that if qemu
> >grows the rest of m68k support (patches have been submitted but not
> >merged), I'll be ready.
> >
> >P.S. If you're bored and want to try my test build for yourself:
> >
> > wget http://impactlinux.com/hg/firmware/archive/tip.tar.bz2
> > tar xvjf tip.tar.bz2
> > cd firmware-*
> > USE_UNSTABLE=linux ./build.sh m68k
> >
> >Without the USE_UNSTABLE=linux it uses 2.6.28 and builds to completion,
> >with it the build uses 2.6.29-rc7 (or whatever URL's listed as the
> >UNSTABLE= value for linux in download.sh) and it breaks trying to add
> >uClibc to the cross compiler.
> >
> >But then anything that actually _uses_ the "make headers_install" output
> >to build stuff against should notice pretty quickly whether or not it
> >#includes missing files.
>
> 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,
so if this is what is required to fix it then yes.
Sam
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-13 8:25 ` Sam Ravnborg
@ 2009-03-13 8:33 ` Geert Uytterhoeven
2009-03-13 8:59 ` Sam Ravnborg
0 siblings, 1 reply; 50+ messages in thread
From: Geert Uytterhoeven @ 2009-03-13 8:33 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Greg Ungerer, Rob Landley, linux-kernel, dwmw2, linux-next
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...
> so if this is what is required to fix it then yes.
Yep, it's a regression from 2.6.28.
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?).
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 [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-13 8:33 ` Geert Uytterhoeven
@ 2009-03-13 8:59 ` Sam Ravnborg
2009-03-13 10:52 ` Greg Ungerer
0 siblings, 1 reply; 50+ messages in thread
From: Sam Ravnborg @ 2009-03-13 8:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Greg Ungerer, Rob Landley, linux-kernel, dwmw2, linux-next
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?).
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.
Sam
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-13 8:59 ` Sam Ravnborg
@ 2009-03-13 10:52 ` Greg Ungerer
2009-03-13 12:14 ` Geert Uytterhoeven
0 siblings, 1 reply; 50+ messages in thread
From: Greg Ungerer @ 2009-03-13 10:52 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Geert Uytterhoeven, Rob Landley, linux-kernel, dwmw2, linux-next
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?
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 :-(
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?
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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-13 10:52 ` Greg Ungerer
@ 2009-03-13 12:14 ` Geert Uytterhoeven
0 siblings, 0 replies; 50+ 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
@ 2009-03-13 12:14 ` Geert Uytterhoeven
0 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-13 12:14 ` Geert Uytterhoeven
@ 2009-03-16 12:40 ` Greg Ungerer
-1 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-13 12:14 ` Geert Uytterhoeven
(?)
(?)
@ 2009-03-16 12:40 ` Greg Ungerer
-1 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
@ 2009-03-16 12:40 ` Greg Ungerer
0 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-16 12:40 ` Greg Ungerer
@ 2009-03-16 20:20 ` Rob Landley
-1 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-16 12:40 ` Greg Ungerer
(?)
@ 2009-03-16 20:20 ` Rob Landley
-1 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
@ 2009-03-16 20:20 ` Rob Landley
0 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-16 20:20 ` Rob Landley
(?)
@ 2009-03-16 22:08 ` Geert Uytterhoeven
2009-03-16 23:09 ` Greg Ungerer
-1 siblings, 1 reply; 50+ 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] 50+ 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; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-16 20:20 ` Rob Landley
@ 2009-03-16 23:10 ` Greg Ungerer
-1 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
@ 2009-03-16 23:10 ` Greg Ungerer
0 siblings, 0 replies; 50+ 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] 50+ 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
-1 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
@ 2009-03-18 4:03 ` Rob Landley
0 siblings, 0 replies; 50+ 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] 50+ 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
-1 siblings, 0 replies; 50+ 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] 50+ 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
-1 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
@ 2009-03-18 5:34 ` Greg Ungerer
0 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-18 5:34 ` Greg Ungerer
@ 2009-03-18 18:12 ` Rob Landley
-1 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-18 5:34 ` Greg Ungerer
(?)
@ 2009-03-18 18:12 ` Rob Landley
-1 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
@ 2009-03-18 18:12 ` Rob Landley
0 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-18 18:12 ` Rob Landley
@ 2009-03-18 23:53 ` Greg Ungerer
-1 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-18 18:12 ` Rob Landley
(?)
@ 2009-03-18 23:53 ` Greg Ungerer
-1 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
@ 2009-03-18 23:53 ` Greg Ungerer
0 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-18 18:12 ` Rob Landley
@ 2009-03-19 7:59 ` Geert Uytterhoeven
-1 siblings, 0 replies; 50+ 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
@ 2009-03-19 7:59 ` Geert Uytterhoeven
0 siblings, 0 replies; 50+ 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] 50+ 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
-1 siblings, 0 replies; 50+ 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] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-03-12 9:37 make headers_install broken for ARCH=m68k in 2.6.29-rc7 Rob Landley
2009-03-12 9:58 ` Sam Ravnborg
@ 2009-04-01 16:57 ` Lennart Sorensen
2009-04-01 19:03 ` Sam Ravnborg
1 sibling, 1 reply; 50+ messages in thread
From: Lennart Sorensen @ 2009-04-01 16:57 UTC (permalink / raw)
To: Rob Landley; +Cc: linux-kernel, dwmw2
On Thu, Mar 12, 2009 at 04:37:03AM -0500, Rob Landley wrote:
> So I'm doing this:
>
> make ARCH=m68k headers_install INSTALL_HDR_PATH=walrus
>
> And it doesn't install unistd_mm.h which is included from asm/unistd.h. (The
> file is there in arch/m68k/include/asm/unistd_mm.h, it just doesn't get
> installed. So any code that #includes <asm/unistd.h> results in a file not
> found error for the other one, which is essentially just a wrapper.)
>
> I don't understand what the code's currently doing here well enough to fix it,
> specifically where does this file list come from? The file
> arch/m68k/include/asm/Kbuild is adding "cachectl.h" to header-y, but there are
> 31 files getting installed from that directory and only one in there. If the
> list was just the contents of the directory, then unistd_mm.h (and
> unistd_no.h) would get installed, but they don't. I could add those two to
> the Kbuild file after cachectl.h, but is that the _right_ fix? Where are the
> other 31 identified? (Is it getting a listing of some _other_ directory?)
I sent a patch to fix that on Feb 5th. I guess it hasn't been put in.
It looked like this:
Signed-of-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
diff --git a/arch/m68k/include/asm/Kbuild b/arch/m68k/include/asm/Kbuild
index 1a922fa..d477927 100644
--- a/arch/m68k/include/asm/Kbuild
+++ b/arch/m68k/include/asm/Kbuild
@@ -1,2 +1,18 @@
include include/asm-generic/Kbuild.asm
header-y += cachectl.h
+header-y += param_mm.h
+header-y += param_no.h
+header-y += ptrace_mm.h
+header-y += ptrace_no.h
+header-y += setup_mm.h
+header-y += setup_no.h
+header-y += sigcontext_mm.h
+header-y += sigcontext_no.h
+header-y += siginfo_mm.h
+header-y += siginfo_no.h
+header-y += signal_mm.h
+header-y += signal_no.h
+header-y += swab_mm.h
+header-y += swab_no.h
+header-y += unistd_mm.h
+header-y += unistd_no.h
--
Len Sorensen
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-04-01 16:57 ` Lennart Sorensen
@ 2009-04-01 19:03 ` Sam Ravnborg
2009-04-01 19:48 ` Lennart Sorensen
0 siblings, 1 reply; 50+ messages in thread
From: Sam Ravnborg @ 2009-04-01 19:03 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: Rob Landley, linux-kernel, dwmw2
On Wed, Apr 01, 2009 at 12:57:41PM -0400, Lennart Sorensen wrote:
> On Thu, Mar 12, 2009 at 04:37:03AM -0500, Rob Landley wrote:
> > So I'm doing this:
> >
> > make ARCH=m68k headers_install INSTALL_HDR_PATH=walrus
> >
> > And it doesn't install unistd_mm.h which is included from asm/unistd.h. (The
> > file is there in arch/m68k/include/asm/unistd_mm.h, it just doesn't get
> > installed. So any code that #includes <asm/unistd.h> results in a file not
> > found error for the other one, which is essentially just a wrapper.)
> >
> > I don't understand what the code's currently doing here well enough to fix it,
> > specifically where does this file list come from? The file
> > arch/m68k/include/asm/Kbuild is adding "cachectl.h" to header-y, but there are
> > 31 files getting installed from that directory and only one in there. If the
> > list was just the contents of the directory, then unistd_mm.h (and
> > unistd_no.h) would get installed, but they don't. I could add those two to
> > the Kbuild file after cachectl.h, but is that the _right_ fix? Where are the
> > other 31 identified? (Is it getting a listing of some _other_ directory?)
>
> I sent a patch to fix that on Feb 5th. I guess it hasn't been put in.
>
> It looked like this:
>
> Signed-of-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
>
> diff --git a/arch/m68k/include/asm/Kbuild b/arch/m68k/include/asm/Kbuild
> index 1a922fa..d477927 100644
> --- a/arch/m68k/include/asm/Kbuild
> +++ b/arch/m68k/include/asm/Kbuild
> @@ -1,2 +1,18 @@
> include include/asm-generic/Kbuild.asm
> header-y += cachectl.h
> +header-y += param_mm.h
> +header-y += param_no.h
> +header-y += ptrace_mm.h
> +header-y += ptrace_no.h
> +header-y += setup_mm.h
> +header-y += setup_no.h
> +header-y += sigcontext_mm.h
> +header-y += sigcontext_no.h
> +header-y += siginfo_mm.h
> +header-y += siginfo_no.h
> +header-y += signal_mm.h
> +header-y += signal_no.h
> +header-y += swab_mm.h
> +header-y += swab_no.h
> +header-y += unistd_mm.h
> +header-y += unistd_no.h
They decided to fix it by eliminating the *_{no,mm}.h files for exported headers.
The patch is already in mainline.
Sam
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-04-01 19:03 ` Sam Ravnborg
@ 2009-04-01 19:48 ` Lennart Sorensen
2009-04-01 20:23 ` Geert Uytterhoeven
0 siblings, 1 reply; 50+ messages in thread
From: Lennart Sorensen @ 2009-04-01 19:48 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Rob Landley, linux-kernel, dwmw2
On Wed, Apr 01, 2009 at 09:03:40PM +0200, Sam Ravnborg wrote:
> They decided to fix it by eliminating the *_{no,mm}.h files for exported headers.
> The patch is already in mainline.
Oh good. Yay! Just didn't make it into 2.6.29 I suspect. Well there
is always 2.6.30.
--
Len Sorensen
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-04-01 19:48 ` Lennart Sorensen
@ 2009-04-01 20:23 ` Geert Uytterhoeven
2009-04-01 22:59 ` Lennart Sorensen
0 siblings, 1 reply; 50+ messages in thread
From: Geert Uytterhoeven @ 2009-04-01 20:23 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: Sam Ravnborg, Rob Landley, linux-kernel, dwmw2
On Wed, Apr 1, 2009 at 21:48, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> On Wed, Apr 01, 2009 at 09:03:40PM +0200, Sam Ravnborg wrote:
>> They decided to fix it by eliminating the *_{no,mm}.h files for exported headers.
>> The patch is already in mainline.
>
> Oh good. Yay! Just didn't make it into 2.6.29 I suspect. Well there
> is always 2.6.30.
It entered mainline just before v2.6.29 (after v2.6.29-rc8)?
Or did you find a new problem?
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 [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-04-01 20:23 ` Geert Uytterhoeven
@ 2009-04-01 22:59 ` Lennart Sorensen
2009-04-02 2:14 ` Rob Landley
0 siblings, 1 reply; 50+ messages in thread
From: Lennart Sorensen @ 2009-04-01 22:59 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Sam Ravnborg, Rob Landley, linux-kernel, dwmw2
On Wed, Apr 01, 2009 at 10:23:06PM +0200, Geert Uytterhoeven wrote:
> It entered mainline just before v2.6.29 (after v2.6.29-rc8)?
> Or did you find a new problem?
No, I just didn't check yet. I am still solving uclibc issues, so
2.6.29-rc3 was still doing the job.
--
Len Sorensen
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-04-01 22:59 ` Lennart Sorensen
@ 2009-04-02 2:14 ` Rob Landley
2009-04-02 21:59 ` Lennart Sorensen
0 siblings, 1 reply; 50+ messages in thread
From: Rob Landley @ 2009-04-02 2:14 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: Geert Uytterhoeven, Sam Ravnborg, linux-kernel, dwmw2
On Wednesday 01 April 2009 17:59:16 Lennart Sorensen wrote:
> On Wed, Apr 01, 2009 at 10:23:06PM +0200, Geert Uytterhoeven wrote:
> > It entered mainline just before v2.6.29 (after v2.6.29-rc8)?
> > Or did you find a new problem?
>
> No, I just didn't check yet. I am still solving uclibc issues, so
> 2.6.29-rc3 was still doing the job.
uClibc's working for me just fine. Either grab the most recent build scripts
from http://impactlinux.com/hg/firmware or grab the prebuilt binaries from
http://impactlinux.com/fwl/downloads/snapshots/ (which has cross compilers,
root filesystem tarballs, and system images bootable by qemu).
I haven't tested m68k yet because qemu doesn't support it (just coldfire), and
aranym hasn't got a serial console, but it did compile using the same build
scripts as all the other targets...
Rob
--
GPLv3 is to GPLv2 what Attack of the Clones is to The Empire Strikes Back.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-04-02 2:14 ` Rob Landley
@ 2009-04-02 21:59 ` Lennart Sorensen
2009-04-03 0:24 ` Rob Landley
0 siblings, 1 reply; 50+ messages in thread
From: Lennart Sorensen @ 2009-04-02 21:59 UTC (permalink / raw)
To: Rob Landley; +Cc: Geert Uytterhoeven, Sam Ravnborg, linux-kernel, dwmw2
On Wed, Apr 01, 2009 at 09:14:05PM -0500, Rob Landley wrote:
> uClibc's working for me just fine. Either grab the most recent build scripts
> from http://impactlinux.com/hg/firmware or grab the prebuilt binaries from
> http://impactlinux.com/fwl/downloads/snapshots/ (which has cross compilers,
> root filesystem tarballs, and system images bootable by qemu).
>
> I haven't tested m68k yet because qemu doesn't support it (just coldfire), and
> aranym hasn't got a serial console, but it did compile using the same build
> scripts as all the other targets...
Well my uclibc issues using 0.9.30.1 are:
When using msh from busybox compiled with gcc 4.3.3 for m68k-uclinux with
-msep-data -mcpu=5271, only one pipe works. Doing two pipes in a command
gives no output.
ie:
# echo 123 | cat
123
# echo 123 | cat | cat
<nothing here>
Also after each command I get the message "Illegal instruction", even
though the command always did its job. So not sure if this is a bug
in msh of the current busybox release, or a bug in uclibc or gcc or
whichever. Still searching. I intend to try out sash soon to see if
it behaves any differently.
--
Len Sorensen
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-04-02 21:59 ` Lennart Sorensen
@ 2009-04-03 0:24 ` Rob Landley
2009-04-03 4:10 ` Lennart Sorensen
0 siblings, 1 reply; 50+ messages in thread
From: Rob Landley @ 2009-04-03 0:24 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: Geert Uytterhoeven, Sam Ravnborg, linux-kernel, dwmw2
On Thursday 02 April 2009 16:59:26 Lennart Sorensen wrote:
> On Wed, Apr 01, 2009 at 09:14:05PM -0500, Rob Landley wrote:
> > uClibc's working for me just fine. Either grab the most recent build
> > scripts from http://impactlinux.com/hg/firmware or grab the prebuilt
> > binaries from http://impactlinux.com/fwl/downloads/snapshots/ (which has
> > cross compilers, root filesystem tarballs, and system images bootable by
> > qemu).
> >
> > I haven't tested m68k yet because qemu doesn't support it (just
> > coldfire), and aranym hasn't got a serial console, but it did compile
> > using the same build scripts as all the other targets...
>
> Well my uclibc issues using 0.9.30.1 are:
>
> When using msh from busybox compiled with gcc 4.3.3 for m68k-uclinux with
Here I'm using bash 2.05b, using gcc 4.2.1 (last gplv2 release), building the
with-mmu target, and I haven't actually got a test environment to boot the
result in working yet, so yeah.
Rob
--
GPLv3 is to GPLv2 what Attack of the Clones is to The Empire Strikes Back.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
2009-04-03 0:24 ` Rob Landley
@ 2009-04-03 4:10 ` Lennart Sorensen
0 siblings, 0 replies; 50+ messages in thread
From: Lennart Sorensen @ 2009-04-03 4:10 UTC (permalink / raw)
To: Rob Landley; +Cc: Geert Uytterhoeven, Sam Ravnborg, linux-kernel, dwmw2
On Thu, Apr 02, 2009 at 07:24:35PM -0500, Rob Landley wrote:
> Here I'm using bash 2.05b, using gcc 4.2.1 (last gplv2 release), building the
> with-mmu target, and I haven't actually got a test environment to boot the
> result in working yet, so yeah.
I don't want to go back to 4.2.x though, I want current "stable" releases. :)
4.3 did change the abi for m68knommu it seems, which has caused trouble
compiling uboot, although the kernel compiles and works fine.
bash compiles on nommu systems? I suspect not. Given I am working with
a coldfire 5271, mmu isn't an option, so I am stuck in crappy no fork
or other useful stuff land. At least the main cpu is a nice sane powerpc
running proper linux.
--
Len Sorensen
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2009-04-03 4:10 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-12 9:37 make headers_install broken for ARCH=m68k in 2.6.29-rc7 Rob Landley
2009-03-12 9:58 ` Sam Ravnborg
2009-03-12 20:03 ` Rob Landley
2009-03-12 20:58 ` Sam Ravnborg
2009-03-12 23:24 ` Stephen Rothwell
2009-03-12 21:02 ` Sam Ravnborg
2009-03-12 22:40 ` Geert Uytterhoeven
2009-03-13 3:25 ` Rob Landley
2009-03-13 7:04 ` Greg Ungerer
2009-03-13 8:25 ` Sam Ravnborg
2009-03-13 8:33 ` Geert Uytterhoeven
2009-03-13 8:59 ` Sam Ravnborg
2009-03-13 10:52 ` Greg Ungerer
2009-03-13 12:14 ` Geert Uytterhoeven
2009-03-13 12:14 ` Geert Uytterhoeven
2009-03-16 12:40 ` Greg Ungerer
2009-03-16 12:40 ` Greg Ungerer
2009-03-16 20:20 ` Rob Landley
2009-03-16 20:20 ` Rob Landley
2009-03-16 20:20 ` Rob Landley
2009-03-16 22:08 ` Geert Uytterhoeven
2009-03-16 23:09 ` Greg Ungerer
2009-03-16 23:10 ` Greg Ungerer
2009-03-16 23:10 ` Greg Ungerer
2009-03-18 4:03 ` Rob Landley
2009-03-18 4:03 ` Rob Landley
2009-03-18 5:34 ` Greg Ungerer
2009-03-18 5:34 ` Greg Ungerer
2009-03-18 5:34 ` Greg Ungerer
2009-03-18 18:12 ` Rob Landley
2009-03-18 18:12 ` Rob Landley
2009-03-18 18:12 ` Rob Landley
2009-03-18 23:53 ` Greg Ungerer
2009-03-18 23:53 ` Greg Ungerer
2009-03-18 23:53 ` Greg Ungerer
2009-03-19 7:59 ` Geert Uytterhoeven
2009-03-19 7:59 ` Geert Uytterhoeven
2009-03-19 8:41 ` Rob Landley
2009-03-16 12:40 ` Greg Ungerer
2009-03-13 8:25 ` Geert Uytterhoeven
2009-03-13 6:53 ` Greg Ungerer
2009-04-01 16:57 ` Lennart Sorensen
2009-04-01 19:03 ` Sam Ravnborg
2009-04-01 19:48 ` Lennart Sorensen
2009-04-01 20:23 ` Geert Uytterhoeven
2009-04-01 22:59 ` Lennart Sorensen
2009-04-02 2:14 ` Rob Landley
2009-04-02 21:59 ` Lennart Sorensen
2009-04-03 0:24 ` Rob Landley
2009-04-03 4:10 ` Lennart Sorensen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.