Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Rob Landley]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Sam Ravnborg]

> > 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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Stephen Rothwell]

[-- 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 --]

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Sam Ravnborg]

> 
> 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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Geert Uytterhoeven]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Rob Landley]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Greg Ungerer]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Sam Ravnborg]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Geert Uytterhoeven]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Sam Ravnborg]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Greg Ungerer]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Geert Uytterhoeven]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Greg Ungerer]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Rob Landley]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Geert Uytterhoeven]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Greg Ungerer]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Greg Ungerer]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Rob Landley]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Greg Ungerer]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Rob Landley]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Greg Ungerer]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Geert Uytterhoeven]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Rob Landley]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Geert Uytterhoeven]

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

Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

[Greg Ungerer]

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