Userland headers available
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.
Signature · 4 lines
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 }Quoted 9 lines · Mariusz Mazur
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.
Signature · 2 lines
Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Quoted 2 lines · Daniel Jacobowitz
I've done precisely the same thing for Debian - if I find the time, I'll compare...
How much testing did you have?
Quoted 3 lines
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.
Signature · 4 lines
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 }Quoted 3 lines · Daniel Jacobowitz
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
Signature · 4 lines
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]
Quoted 2 lines · 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
Signature · 4 lines
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]
Quoted 3 lines · Daniel Jacobowitz
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
Quoted 7 lines · Chris Friesen
Quoted 4 lines · 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.
Quoted 7 lines
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.
(google linux-kernel include/abi)
Signature · 5 lines
________________________________________________________________ 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
Quoted 8 lines
Quoted 4 lines · 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.
Quoted 8 lines
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
Quoted 23 lines · H. Peter Anvin
Followup to: <[email protected]> By author: Chris Friesen <[email protected]> In newsgroup: linux.dev.kernelQuoted 8 lines
Quoted 4 lines · 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.Quoted 8 lines
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.
Quoted 6 lines
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?
Signature · 2 lines
Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Quoted 4 lines · Daniel Jacobowitz
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