2.6.25: include/asm-ppc vs. include/asm-powerpc

2.6.25: include/asm-ppc vs. include/asm-powerpc

[Paul Smith]

I know that arch/ppc is obsolete in 2.6.26 and deprecated for earlier
releases.  However, I have a port to a custom PPC-based board that was
originally done for 2.6.14 in arch/ppc, and I've ported it to our
current "standard" kernel of 26.25 and it works (anyway it boots etc.)
I absolutely do not have time now, and not for a few months, to convert
over to live in arch/powerpc (BTW, if anyone has any pointers to docs on
ways to make that transition I'm very interested).

My problem is this: I'm having trouble building some of our externel
kernel modules because they can't find various kernel header files.
Looking at the kernel's include directory I see that include/asm is
symlinked to include/asm-ppc which is what I would expect for ARCH=ppc,
and the same way it used to work in 2.6.14.

However, looking in the include/asm-ppc directory I see that many of the
files that used to be there are not there anymore... although they do
appear in include/asm-powerpc.  In particular I'm interested in
ppc_asm.h which used to exist in both asm-ppc64 AND in asm-ppc, but now
only exists in asm-powerpc.  What's the approved way to include this
header if asm points to asm-ppc?

In general it seems like lots of headers that used to be in both asm
directories now appear in only asm-powerpc; I don't really see how this
is supposed to work.  Any tips on this would be most welcome.


Thanks!

Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc

[Arnd Bergmann]

On Thursday 28 August 2008, Paul Smith wrote:
> However, looking in the include/asm-ppc directory I see that many of the
> files that used to be there are not there anymore... although they do
> appear in include/asm-powerpc. =A0In particular I'm interested in
> ppc_asm.h which used to exist in both asm-ppc64 AND in asm-ppc, but now
> only exists in asm-powerpc. =A0What's the approved way to include this
> header if asm points to asm-ppc?
>=20
> In general it seems like lots of headers that used to be in both asm
> directories now appear in only asm-powerpc; I don't really see how this
> is supposed to work. =A0Any tips on this would be most welcome.
>=20

The easiest solution should be to just include all your modules in
the kernel source as patches, rather than building them externally.

That will give you access to all the headers you need.

Of course that is only possible if all your modules are GPL, but I
assume that you would not have asked here if they were not.

	Arnd <><

Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc

[Paul Smith]

On Thu, 2008-08-28 at 15:53 +0200, Arnd Bergmann wrote:
> The easiest solution should be to just include all your modules in
> the kernel source as patches, rather than building them externally.
> 
> That will give you access to all the headers you need.

It doesn't matter whether I build my code in the kernel as patches, or
not.  The problem is not that I don't have the headers handy, it's that
they simply don't exist in asm-ppc anymore, not even in the linux source
tree.

There is no asm-ppc/ppc_asm.h in the kernel anymore.  In my code that
includes it, where ARCH=ppc and include/asm is linked to asm-ppc, how do
I get ahold of that file?  I can't use #include <asm/ppc_asm.h> like I
used to.  Do I have to use #include <asm-powerpc/ppc_asm.h> explicitly?
At least this will work... but read on:

Even more troublesome are headers like <linux/posix_types.h>, which
includes <asm/posix_types.h>, but there IS NO asm-ppc/posix_types.h file
in the kernel tree!  There is only an asm-powerpc/posix_types.h... but
if asm is a link to asm-ppc, this fails and I have no way to fix it!

On the other hand, if I cheat and set the asm symlink pointing to
asm-powerpc instead, then when I include files like <linux/interrupt.h>.
which includes <linux/hardirq.h>, which includes <asm/hardirq.h>, which
(because I have CONFIG_40X defined) includes <asm/ibm44x.h>, I get the
opposite problem: there is no asm-powerpc/ibm4xx.h; that header exists
only in the asm-ppc directory.  So now THAT include fails.



I seem to be out of luck here.

Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc

[Josh Boyer]

On Thu, Aug 28, 2008 at 10:30:48AM -0400, Paul Smith wrote:
>On Thu, 2008-08-28 at 15:53 +0200, Arnd Bergmann wrote:
>> The easiest solution should be to just include all your modules in
>> the kernel source as patches, rather than building them externally.
>> 
>> That will give you access to all the headers you need.
>
>It doesn't matter whether I build my code in the kernel as patches, or
>not.  The problem is not that I don't have the headers handy, it's that
>they simply don't exist in asm-ppc anymore, not even in the linux source
>tree.

Then you need to adapt your code to where ever that information moved
to?  Maybe if you post your driver code and makefile we can help you
out.

>There is no asm-ppc/ppc_asm.h in the kernel anymore.  In my code that
>includes it, where ARCH=ppc and include/asm is linked to asm-ppc, how do
>I get ahold of that file?  I can't use #include <asm/ppc_asm.h> like I
>used to.  Do I have to use #include <asm-powerpc/ppc_asm.h> explicitly?
>At least this will work... but read on:
>
>Even more troublesome are headers like <linux/posix_types.h>, which
>includes <asm/posix_types.h>, but there IS NO asm-ppc/posix_types.h file
>in the kernel tree!  There is only an asm-powerpc/posix_types.h... but
>if asm is a link to asm-ppc, this fails and I have no way to fix it!
>
>On the other hand, if I cheat and set the asm symlink pointing to
>asm-powerpc instead, then when I include files like <linux/interrupt.h>.
>which includes <linux/hardirq.h>, which includes <asm/hardirq.h>, which
>(because I have CONFIG_40X defined) includes <asm/ibm44x.h>, I get the
>opposite problem: there is no asm-powerpc/ibm4xx.h; that header exists
>only in the asm-ppc directory.  So now THAT include fails.

This is all confusing to me.  Things obviously work in-kernel, or it
wouldn't build at all.  There used to be a hack in the ppc makefiles to
add a -Iasm-powerpc (or a symlink or something) so that files _would_ find
the right headers.  Look harder at the makefiles and try to duplicate that
for your external modules.

Or move to the latest git kernel, where this problem doesn't exist at all
since arch/ppc is removed entirely :).

josh

Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc

[Arnd Bergmann]

On Thursday 28 August 2008, Paul Smith wrote:
> On Thu, 2008-08-28 at 15:53 +0200, Arnd Bergmann wrote:
> > The easiest solution should be to just include all your modules in
> > the kernel source as patches, rather than building them externally.
> > 
> > That will give you access to all the headers you need.
> 
> It doesn't matter whether I build my code in the kernel as patches, or
> not.  The problem is not that I don't have the headers handy, it's that
> they simply don't exist in asm-ppc anymore, not even in the linux source
> tree.

The trick that arch/ppc uses is to create a symlink arch/ppc/include/asm
pointing to include/asm-powerpc and then passing "-Iinclude
 -Iarch/ppc/include" to the compiler. This will make gcc look for
headers in asm-ppc first, and then in asm-powerpc.

It should also work with external modules if you build them in the
recommended way (see http://lwn.net/Articles/80250/), but as I said,
the easiest way is to just build all modules as part of the regular
kernel build. It should be evident that building kernel code actually
works and gets the right header files for all existing modules, so
it should work just like that for any drivers you add to the kernel.

	Arnd <><

Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc

[Paul Smith]

On Thu, 2008-08-28 at 16:42 +0200, Arnd Bergmann wrote:
> The trick that arch/ppc uses is to create a symlink
> arch/ppc/include/asm pointing to include/asm-powerpc and then passing
> "-Iinclude  -Iarch/ppc/include" to the compiler. This will make gcc
> look for headers in asm-ppc first, and then in asm-powerpc.
> 
> It should also work with external modules if you build them in the
> recommended way (see http://lwn.net/Articles/80250/),

Hrm... I do build that way (with M=...)... oh, I see.  When the kernel
build performs that trick the arch/ppc/include/asm symlink is pointing
to a fully-qualified pathname, not a relative pathname.  So, when I
export this information and use it somewhere else that link is not
pointing to anything.

Argh.  Well, at least that's something I can fix.  Thanks for the info;
I'll let you know how it goes.

> but as I said, the easiest way is to just build all modules as part of
> the regular kernel build.

It's not really a very easy way in our environment.  We're not primarily
in the business of building the Linux kernel; it's a very small part.
Most of our work is in userspace, and we have a very significant (and
bizarre) build environment there.  I definitely cannot change THAT, at
this point.  We build an initrd once in a blue moon, with a kernel,
busybox, and basic, very static facilities.  Then, we check in the
initrd to our source code control system and almost everyone just uses
that image; they never need to build a kernel or initrd etc. themselves.
However, some of our kernel modules do change pretty frequently and are
much more tightly tied to our userspace stuff, so if we tried to put
them into the kernel tree it would be constantly changing and it would
be a mess; we need to keep those in our normal source code control area
along with our other code.  So, I create a kernel sysroot kit and check
that in with the initrd, then unpack it to build the kernel modules.

Plus, we're using a development environment provided by WindRiver so the
build model for the kernel/initrd is that what we check in is a
compressed tarball with the basic kernel sources, plus a series of
patches; these are unpacked/applied when you build the initrd (kind of
like a Red Hat SRPM).  This kind of "development by patches" is just not
feasible for anything that is continuously updated (IMO).  If we were
fully invested in the entire kernel development model, with git for
source code control etc., then things would be simpler (for this
anyway).  But that's not how we're doing things.

It's not a licensing thing: it's a development model thing.

Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc

[Paul Smith]

On Thu, 2008-08-28 at 16:42 +0200, Arnd Bergmann wrote:
> The trick that arch/ppc uses is to create a symlink
> arch/ppc/include/asm pointing to include/asm-powerpc and then passing
> "-Iinclude -Iarch/ppc/include" to the compiler.

Aha!!

Changing that arch/ppc/include/asm symlink to be relative
(-> ../../../include/asm-powerpc) instead of absolute solves all these
problems!

Now I'm just down to real portability issues (since the drivers were
originally written for 2.6.14).


Thanks very much!

Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc

[Roland Dreier]

 > It doesn't matter whether I build my code in the kernel as patches, or
 > not.  The problem is not that I don't have the headers handy, it's that
 > they simply don't exist in asm-ppc anymore, not even in the linux source
 > tree.

I believe that the kernel's build system (before arch/ppc was removed
entirely) had some magic to include files from asm-powerpc if they
didn't exist in asm-ppc.  So building your code with the kernel's build
system (and Documentation/kbuild/modules.txt explains how to do that
even without building in the kernel tree itself) should work.

For example, the reason include/asm-ppc/ppc_asm.h doesn't exist is
because of commit 5f7c6907, which moved the file to asm-powerpc.

 - R.

Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc

[Darcy Watkins]

Hi Paul,

A hack we did when building a ported WiMax driver against 2.6.19 was to
merge the two asm-p.*pc directories.

Below is a snippet from one of our build scripts that does this.
Assuming KERNEL_SRC_PATH is set to point to your kernel source...

#------------------
if [ ! -d $KERNEL_SRC_PATH/include/asm-ppc-merged ]; then
echo "Creating a merged include/asm for arch/ppc and arch/powerpc"
mkdir $KERNEL_SRC_PATH/include/asm-ppc-merged
cp -r $KERNEL_SRC_PATH/include/asm-powerpc/* $KERNEL_SRC_PATH/include/asm-ppc-merged
cp -r $KERNEL_SRC_PATH/include/asm-ppc/* $KERNEL_SRC_PATH/include/asm-ppc-merged
fi

echo "Symlinking the merged include/asm"
cd $KERNEL_SRC_PATH/include
rm asm
ln -s asm-ppc-merged asm
#------------------

Based on this order, files from arch/ppc win but missing files will come
from arch/powerpc.

You could try it out.  Mileage may vary, especially newer than 2.6.23
since there may be device tree dependent stuff that gets into the merged
directory.  We stopped using this hack for kernel 2.6.23 and newer since
we migrated to arch/powerpc for 2.6.23 and later (presently using
2.6.25) so I really don't know whether or not it will work for you.

If you use the symlinked shadow source tree facility of the Xenomai
build with your kernel, then use "-rs" instead of "-r" in the "cp"'s
above.  Otherwise just use "-r" as shown above.

Regards,

Darcy


On Thu, 2008-08-28 at 06:07 -0700, Paul Smith wrote:
--snip!--
> In general it seems like lots of headers that used to be in both asm
> directories now appear in only asm-powerpc; I don't really see how
> this
> is supposed to work.  Any tips on this would be most welcome.
--snip!--
-- 


Regards,

Darcy

--------------
Darcy L. Watkins - Senior Software Developer
Tranzeo Wireless Technologies, Inc.
19273 Fraser Way, Pitt Meadows, BC, Canada V3Y 2V4
T:604-460-6002 ext:410
http://www.tranzeo.com