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

[Paul Smith <paul@mad-scientist.us>]

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.