At http://ep09.pld-linux.org/~mmazur/glibc-kernel-headers/ there are userland
headers for linux, derived from 2.6 kernels with lots of 2.4 compatibility
fixes. CVS repo can be found at cvs.pld-linux.org/glibc-kernel-headers (anon
and webcvs). These headers are currently used to compile a whole linux distro
(ftp.pld-linux.org/dists/ac) for x86, sparc, amd64, alpha and ppc, but
general fixes are applied to all archs since we never know if a new arch
won't be added (amd64 was added just a month-two ago). #1 feature is that
they are and will be maintained (currently three people are working on them)
and bugs are mostly fixed instantly. Enjoy.
--
Ka?dy cz?owiek, kt?ry naprawd? ?yje, nie ma charakteru, nie mo?e go mie?.
Charakter jest zawsze martwy, otacza ci? zgni?a struktura przeniesiona z
przesz?o?ci. Je?eli dzia?asz zgodnie z charakterem wtedy nie dzia?asz w og?le
- jedynie mechanicznie reagujesz. { Osho }
On Fri, Jan 23, 2004 at 07:07:17PM +0100, Mariusz Mazur wrote:
> At http://ep09.pld-linux.org/~mmazur/glibc-kernel-headers/ there are userland
> headers for linux, derived from 2.6 kernels with lots of 2.4 compatibility
> fixes. CVS repo can be found at cvs.pld-linux.org/glibc-kernel-headers (anon
> and webcvs). These headers are currently used to compile a whole linux distro
> (ftp.pld-linux.org/dists/ac) for x86, sparc, amd64, alpha and ppc, but
> general fixes are applied to all archs since we never know if a new arch
> won't be added (amd64 was added just a month-two ago). #1 feature is that
> they are and will be maintained (currently three people are working on them)
> and bugs are mostly fixed instantly. Enjoy.
I've done precisely the same thing for Debian - if I find the time,
I'll compare...
I would really like to come up with an approach to maintain this
interface definition in the kernel source. I'm still trying to think
of a way to do it without breaking compatibility or kernel builds.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Daniel Jacobowitz wrote:
> I would really like to come up with an approach to maintain this
interface
> definition in the kernel source. I'm still trying to think of a
> way to do it without breaking compatibility or kernel builds.
The obvious way is to have the kernel headers include the userland
headers, then everything below that be wrapped in "#ifdef __KERNEL__".
Userland then includes the normal kernel headers, but only gets the
userland-safe ones.
This sounds too easy though--I'm sure I've missed something, but I can't
think what....
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Friday 23 of January 2004 19:47, Daniel Jacobowitz wrote:
> I've done precisely the same thing for Debian - if I find the time,
> I'll compare...
How much testing did you have?
> I would really like to come up with an approach to maintain this
> interface definition in the kernel source. I'm still trying to think
> of a way to do it without breaking compatibility or kernel builds.
As I really would like that (less work for me :) I do not think this is
possible. First thing - 2.4 compatibility in 2.6 kernel would seem weird to
say at least. Second - I've ripped out kernel code where I could and used
glibc includes instead - this is (a) The Right Thing (tm) and (b) practically
undoable inside kernel or would require huge amounts of work, which is really
better of left outside.
--
Ka?dy cz?owiek, kt?ry naprawd? ?yje, nie ma charakteru, nie mo?e go mie?.
Charakter jest zawsze martwy, otacza ci? zgni?a struktura przeniesiona z
przesz?o?ci. Je?eli dzia?asz zgodnie z charakterem wtedy nie dzia?asz w og?le
- jedynie mechanicznie reagujesz. { Osho }
Friesen, Christopher [CAR:7Q28:EXCH] wrote:
> The obvious way is to have the kernel headers include the userland
> headers, then everything below that be wrapped in "#ifdef __KERNEL__".
> Userland then includes the normal kernel headers, but only gets the
> userland-safe ones.
I just realized this wasn't clear. I envision a new set of headers in
the kernel that are clean to export to userland. The current headers
then include the appropriate userland-clean ones, and everything below
that is kernel only.
This lets the kernel maintain the userland-clean headers explicitly, and
we don't have the work of cleaning them up for glibc.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Fri, Jan 23, 2004 at 01:47:55PM -0500, Daniel Jacobowitz wrote:
> I would really like to come up with an approach to maintain this
> interface definition in the kernel source. I'm still trying to think
> of a way to do it without breaking compatibility or kernel builds.
Yell if you need any kbuild related help.
Sam
On Fri, Jan 23, 2004 at 02:39:57PM -0500, Chris Friesen wrote:
> Friesen, Christopher [CAR:7Q28:EXCH] wrote:
>
> >The obvious way is to have the kernel headers include the userland
> >headers, then everything below that be wrapped in "#ifdef __KERNEL__".
> >Userland then includes the normal kernel headers, but only gets the
> >userland-safe ones.
>
> I just realized this wasn't clear. I envision a new set of headers in
> the kernel that are clean to export to userland. The current headers
> then include the appropriate userland-clean ones, and everything below
> that is kernel only.
>
> This lets the kernel maintain the userland-clean headers explicitly, and
> we don't have the work of cleaning them up for glibc.
This gets discussed every few months. I think the most
recent was in August.
http://groups.google.com/groups?q=linux-kernel+include/abi&hl=en&lr=&ie=UTF-8&selm=lXHU.431.1%40gated-at.bofh.it&rnum=1
(google linux-kernel include/abi)
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
Followup to: <[email protected]>
By author: Chris Friesen <[email protected]>
In newsgroup: linux.dev.kernel
>
> Friesen, Christopher [CAR:7Q28:EXCH] wrote:
>
> > The obvious way is to have the kernel headers include the userland
> > headers, then everything below that be wrapped in "#ifdef __KERNEL__".
> > Userland then includes the normal kernel headers, but only gets the
> > userland-safe ones.
>
> I just realized this wasn't clear. I envision a new set of headers in
> the kernel that are clean to export to userland. The current headers
> then include the appropriate userland-clean ones, and everything below
> that is kernel only.
>
> This lets the kernel maintain the userland-clean headers explicitly, and
> we don't have the work of cleaning them up for glibc.
>
We've referred to this for quite a while as the "ABI header project";
it's been targetted for 2.7, since it missed the 2.6 freeze.
We have set up a mailing list at:
http://zytor.com/mailman/listinfo/linuxabi
The goal is to get a formal exportable version of the kernel ABI that
user-space libraries can use.
-hpa
On Sat, Jan 24, 2004 at 01:38:06AM +0000, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Chris Friesen <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > Friesen, Christopher [CAR:7Q28:EXCH] wrote:
> >
> > > The obvious way is to have the kernel headers include the userland
> > > headers, then everything below that be wrapped in "#ifdef __KERNEL__".
> > > Userland then includes the normal kernel headers, but only gets the
> > > userland-safe ones.
> >
> > I just realized this wasn't clear. I envision a new set of headers in
> > the kernel that are clean to export to userland. The current headers
> > then include the appropriate userland-clean ones, and everything below
> > that is kernel only.
> >
> > This lets the kernel maintain the userland-clean headers explicitly, and
> > we don't have the work of cleaning them up for glibc.
> >
>
> We've referred to this for quite a while as the "ABI header project";
> it's been targetted for 2.7, since it missed the 2.6 freeze.
>
> We have set up a mailing list at:
>
> http://zytor.com/mailman/listinfo/linuxabi
>
> The goal is to get a formal exportable version of the kernel ABI that
> user-space libraries can use.
Are the list archives broken, or has there never been traffic on this
list?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Daniel Jacobowitz wrote:
>
> Are the list archives broken, or has there never been traffic on this
> list?
>
There was some traffic on the klibc list, but I don't think things got
started after the new list was created.
-hpa