> They supply their own. Witness modutils. There's really no other way
> to live with multiple kernel trees, and the interface _cannot_ change
> so quickly as to keep the kernel headers and the application headers
> continually out of sync. Otherwise you break binaries right and left
> and no one likes that either.
Not very good... and in the modutils case mostly to be able to use an
outdated, broken interfase. I know, I've been hacking on this and related
stuff some.
> > This is crazy I think.
> Straw men all. At issue is
>
> (1) The desire to provide surgically clean namespaces for
> ISO C, POSIX, and XPG4.
OK, but that's mostly for _application_ programs. Stuff like modutils et al
have no chance at all to work elsewhere, so portability is moot.
> (2) We don't want to worry about what kernel's headers are
> installed so that things work properly.
OK.
> (3) Linus doesn't want to be prevented from some particular
> cleanup because of what it might do to libc.
Very true.
> (4) The desire to present a constant binary interface in the
> face of a number of planned kernel changes.
To whom? kernel-dependent stuff like modutils, ifconfig, &c just can't be
done fully that way.
There is the kernel itself, programs closely tied to the kernel (such as
modutils) that _have_ to get a peek under the hood to have any chance of
surviving when stuff in the kernel changes, and regular application
programs. For the last category I fully agree.
> We've been over and over this issue. Userland programs not
> using kernel headers is the only sensible solution. This is
> not just some bogus rule of thumb I came up with on the spur
> of the moment.
There is userland, kernel sea and systems shore ;-)
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513