On Saturday 22 April 2006 10:50 am, Adrian Bunk wrote:
> > > These are two doable approaches with a new kabi/ that avoid needless
> > > breaking of userspace.
> >
> > First off:
> > There are many other users that poke direct in the kernel source also.
>
> Kernel space users?
> User space users?
>
> Can you give an example of what you are thinking of?
Busybox's losetup code wants linux/loop.c because nothing else #defines that
structure, and cut and pasting it into a local header file is incredibly
painful because portions of that structure vary by architecture, namely
__kernel_dev_t has different sizes on alpha, arm, x86... meaning we have to
#include linux/posix_types.h unless we want to hard wire into our code
#ifdefs that type for every architecture out there. This is _bypassing_ the
fact that we already #include linux/version.h and check if we're building on
2.6, and if so just use the 64 bit structure instead to avoid the whole
_old_kernel_dev_t rename entirely.
We spent _two years_ trying to figure out a clean way to do all that. There
isn't one.
And no, util-linux isn't doing it cleanly either. They just hide the ugliness
by nesting #include files. mount/loop.h #includes my_dev_t.h which #includes
<linux/posix_types.h> and <linux/version.h> just like we do, because THERE IS
NO ALTERNATIVE.
I've been using Mazur's cleaned up headers (still am, it's stuck on 2.6.12 but
that still works until something better comes along). I've been tracking
various attempts to come up with a successor.
The gentoo people have been collecting patches to clean up the headers:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/src/patchsets/gentoo-headers/?root=gentoo
Plus usable headers and a sanitizing script:
http://packages.gentoo.org/search/?sstring=linux-headers
http://packages.gentoo.org/search/?sstring=genkernel
The cross-linux-from-scratch people have been working on their own header
sanitizing script:
http://headers.cross-lfs.org
http://cross-lfs.org/view/svn/ppc/final-system/linux-headers.html
http://ninja.linux-phreak.biz/pipermail/clfs-dev/2006-April/000007.html
http://ninja.linux-phreak.biz/pipermail/clfs-dev/2006-April/000019.html
http://ninja.linux-phreak.biz/pipermail/clfs-dev/2006-April/000027.html
Fedora recently migrated from a linux-kernel-headers package that smells a bit
like Mazur's to the glibc-kernheaders package. Debian has its own patches
for this... There have been LOTS of attempts to clean up all the #ifdef
KERNEL stuff
I'm am _thrilled_ that somebody's trying to create a path into the kernel for
all these diverse efforts, because this is important to a lot of people and
we can't wait two years for a big flag day kabi effort to possibly become
useful someday.
The beauty of the "make headers_install" thing is I don't have to wait for it
to be finished before I can use it. It's no worse than the current
situation, and it's something I can collect and maintain existing patches
against, something I can _submit_ patches against.
P.S. I spent yesterday dealing with this stuff. Why? I want to build a
cross-compiler for arm, using gcc 4.1.0. But gcc doesn't just require a
cross version of binutils, it also requires headers for the target platform
(because now stack unwinding is built even if you disable c++ support).
These target headers come from your cross-compiled C library. You need a
cross compiler to build that C library. And you need the library to build
the cross compiler.
Luckily, uClibc has a "make headers" that can use the native compiler. But
the uClibc build requires the correct kernel headers preprepared for the
target platform you're going to build for when you do that. And so, I
dredged up Mazur's 2.6.12 headers again. It's that or use the raw ones from
linux-2.6.16...
> > Secondly and more importantly:
> > Introducing kabi/ you will have a half solution where several users will
> > have to find their stuff in two places for a longer period.
> > kabi/ does not allow you to do it incrementally - it requires you to
> > move everything over from a start.
> > You may argue that you can just move over a little bit mroe than needed
> > but then we ruin the incremental approach.
>
> For kernel space, you can do it incrementally, since the whole kabi/
> stuff should be transparent for in-kernel uses.
kabi does not exist yet, and it will be useless to me until it's finished.
Wake me when you've teleported from point A to point B with no road in
between. In the meantime, I'm happy to test the incremental cleanup and
report any problems I have with it, possibly with patches if I manage to fix
it myself.
Make headers_install interests me, as a consumer of said headers. Today.
Right now. The kabi thing does not interest me, does not serve my needs, and
will not get any effort from me to advance it.
> For user space, you need one switch.
> But this switch goes from the current mess with several independent
> user space header implementations to one official implementation.
We have an official implementation, the existing kernel headers. Its's just
broken. The "make headers_install" approach sounds to me like a marvelous
way to get consistently cleaned up versions of those kernel headers. (I
didn't say perfectly, I said consistently. I can submit patches against
consistently, and I know where to submit them _to_.)
Rob
--
Never bet against the cheap plastic solution.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
