kernel headers & userland

kernel headers & userland

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]

Hi!

Apparently Linus told Felix von Leitner (the author of dietlibc - a small,
no nonsense glibc replacement C library) a while ago _not_ to include any
linux kernel headers in userland (i.e. the C library headers in this case).

This imho is obviously wrong since there are definitely a need for including
kernel headers on a linux platform.

Just the basic stuff for instance:

keyboard: sys/kd.h - needs linux/kd.h
sound: sys/soundcard.h - need linux/soundcard.h
sysctl: sys/sysctl.h - need linux/sysctl.h
vt: sys/vt.h - need linux/vt.h

and so on. Then there's the whole sys/types.h issue which needs
linux/types.h, etc.

Even if you go through the trouble of making a generic sys/types.h and
carefully avoid kernel headers by not defining things like sys/soundcard.h
at all (boy, is this going to break things), you are going to run into lots
of trouble when applications include kernel headers on their own and your
headers (duplicate type definitions - you can hack this that linux kernel
headers override this, but it's a nightmare to manage).

Now, you may argue that userland apps should not include linux kernel
headers either, but sometimes it does. Just look at all userland apps that
needs to interface with kernel subsystems such as v4l, mtd, oss, etc.

Then there's all the ioctl() definitions (e.g. ioctl()'s for ext2, keyboard
leds, etc.)

In short, there is simply too many things that will break if you don't
include linux kernel headers in the C library headers (just look at glibc
for instance).

-- 

Regards
 Abraham

Iron Law of Distribution:
	Them that has, gets.

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: kernel headers & userland

[Eric W. Biederman]

Abraham vd Merwe <abraham@2d3d.co.za> writes:

> Hi!
> 
> Apparently Linus told Felix von Leitner (the author of dietlibc - a small,
> no nonsense glibc replacement C library) a while ago _not_ to include any
> linux kernel headers in userland (i.e. the C library headers in this case).
> 
> This imho is obviously wrong since there are definitely a need for including
> kernel headers on a linux platform.

???  Necessity no.  Are there practical benefits yes.

The policy of the kernel developers in general is that if your apps
includes kernel headers and it breaks, it is a kernel problem.

As for ioctl it is a giant mess that needs to be taken out and shot.

And yes there are places where even the mighty glibc is in the wrong.

Eric

Re: kernel headers & userland

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

Hi Eric!

> > Apparently Linus told Felix von Leitner (the author of dietlibc - a small,
> > no nonsense glibc replacement C library) a while ago _not_ to include any
> > linux kernel headers in userland (i.e. the C library headers in this case).
> > 
> > This imho is obviously wrong since there are definitely a need for including
> > kernel headers on a linux platform.
> 
> ???  Necessity no.  Are there practical benefits yes.
> 
> The policy of the kernel developers in general is that if your apps
> includes kernel headers and it breaks, it is a kernel problem.
> 
> As for ioctl it is a giant mess that needs to be taken out and shot.
> 
> And yes there are places where even the mighty glibc is in the wrong.

Just acknowledging that it is a problem doesn't solve the problem though.
The question remains how you approach the kernel headers issue at the moment?

My guess is the only way is by including the kernel headers for now and
change it one day when someone decides to clean up the mess.

-- 

Regards
 Abraham

Every absurdity has a champion who will defend it.

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: kernel headers & userland

[Alan Cox]

> Apparently Linus told Felix von Leitner (the author of dietlibc - a small,
> no nonsense glibc replacement C library) a while ago _not_ to include any
> linux kernel headers in userland (i.e. the C library headers in this case).

Did Felix make clear that it was a library he was talking about ?

> In short, there is simply too many things that will break if you don't
> include linux kernel headers in the C library headers (just look at glibc
> for instance).

Absolutely. But the main issue is applications. I certainly have no problem
with glibc using kernel header copies. Its when they leak into generic apps
directly it gets ugly

(And note glibc uses copies..)

Re: kernel headers & userland

[Eric W. Biederman]

Abraham vd Merwe <abraham@2d3d.co.za> writes:

> Hi Eric!
> 
> > > Apparently Linus told Felix von Leitner (the author of dietlibc - a small,
> > > no nonsense glibc replacement C library) a while ago _not_ to include any
> > > linux kernel headers in userland (i.e. the C library headers in this case).
> > > 
> > > This imho is obviously wrong since there are definitely a need for including
> 
> > > kernel headers on a linux platform.
> > 
> > ???  Necessity no.  Are there practical benefits yes.
> > 
> > The policy of the kernel developers in general is that if your apps
> > includes kernel headers and it breaks, it is a kernel problem.
> > 
> > As for ioctl it is a giant mess that needs to be taken out and shot.
> > 
> > And yes there are places where even the mighty glibc is in the wrong.
> 
> Just acknowledging that it is a problem doesn't solve the problem though.
> The question remains how you approach the kernel headers issue at the moment?
> 
> My guess is the only way is by including the kernel headers for now and
> change it one day when someone decides to clean up the mess.

Well. I'm not certain which mess you are refering too.  A normal
user space program should never include kernel headers period.  If it
does it should get fixed.   At minimum ``cp include/linux/xx.h . ''

And probably something similiar for libc.

The problem is not that it is evil to include kernel headers but
instead that it is a maintenance nightmare from both the glibc and
the kernel to have one set of headers that satisfy both their.  
purposes.  Perhaps if someone built a set of headers with that in mind
it could work.

Eric