__KERNEL__ removal

__KERNEL__ removal

[Jonathan Lundell]

At 1:38 PM -0400 2001-07-14, Jeff Garzik wrote:
>Alan Cox wrote:
>>  Jeff Garzik wrote:
>>  > it would be nice to remove __KERNEL__ from at least the i386
>>  > kernel headers in 2.5, and I think it's a doable task...
>>
>>  That just generates work for the glibc folks when they are working 
>>off copies
>>  of kernel header snapshots as they need to
>
>It is a flag day change so it generates [a lot of] work once... it has
>always been policy that userspace shouldn't be including kernel
>headers.  uClibc and now dietlibc are following this policy.
>
>IMHO we have made an exception for glibc for long enough...

I take it the policy JG is referring to applies to including any 
kernel header files at all in userspace programs, and that __KERNEL__ 
removal is a mere consequence of that policy.

AC points out that syscall interfaces in glibc are a reasonable 
exception to that policy.

What about a header like ethtool.h? Isn't its whole reason for 
existing to provide a common ABI for ethtool.c and the various 
drivers that support it?

Likewise sockios.h, which ethtool (and no doubt many others) also 
#includes. Unless you're going to encapsulate all possible ioctl 
interfaces into libc, sockios.h (for example) provides a piece of the 
ABI that's needed by the user code, not just by libc. Why would it 
make sense to require retyping of this stuff?

If, on the other hand, the argument is that user-kernel ABI 
definitions should be isolated in their own headers, and not mixed up 
(hence __KERNEL__), that's a much more restricted argument. My 
impression is that this is *not* the argument though; is it?
-- 
/Jonathan Lundell.

Re: __KERNEL__ removal

[Jeff Garzik]

Jonathan Lundell wrote:
> I take it the policy JG is referring to applies to including any
> kernel header files at all in userspace programs, and that __KERNEL__
> removal is a mere consequence of that policy.
> 
> AC points out that syscall interfaces in glibc are a reasonable
> exception to that policy.

> What about a header like ethtool.h? Isn't its whole reason for
> existing to provide a common ABI for ethtool.c and the various
> drivers that support it?

no.  this is counter to the
don't-include-kernel-headers-in-userspace-programs policy.

kernel types are not userspace types, kernel namespace isn't userspace
namespace.

> Likewise sockios.h, which ethtool (and no doubt many others) also
> #includes. Unless you're going to encapsulate all possible ioctl
> interfaces into libc, sockios.h (for example) provides a piece of the
> ABI that's needed by the user code, not just by libc. Why would it
> make sense to require retyping of this stuff?

> If, on the other hand, the argument is that user-kernel ABI
> definitions should be isolated in their own headers, and not mixed up
> (hence __KERNEL__), that's a much more restricted argument. My
> impression is that this is *not* the argument though; is it?

If there -must- be parts of the kernel that are visible to userspace,
yes, we should separate them and make that separation obvious.  I would
not call our current setup obvious :)

IMHO the current __KERNEL__ "policy" is largely unenforced...  It takes
no time at all to find any number of cases (drivers adding ioctls are
the worst) where a header is shared between userspace and kernelspace,
and it pollutes kernel types or structures to userspace, or vice versa.

If we want to avoid the retyping (which is IMHO the most clean
separation for all cases, even if it involves drudgery) then separating
out code into libc-only headers would be nice.

	Jeff


-- 
Jeff Garzik      | A recent study has shown that too much soup
Building 1024    | can cause malaise in laboratory mice.
MandrakeSoft     |

Re: __KERNEL__ removal

[Mo McKinlay]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Today, Jeff Garzik (jgarzik@mandrakesoft.com) wrote:

  > If we want to avoid the retyping (which is IMHO the most clean
  > separation for all cases, even if it involves drudgery) then separating
  > out code into libc-only headers would be nice.

I agree...the "worst" case is that the libc and kernel become out of step.
Big deal. If that was to have a bad effect, then statically-compiled
programs would fail to work as well... and if this happened, well, it'd
generally be universally accepted as a bug in the particular release of
the kernel.

I know it takes time and effort, but so does fixing and working around all
of the problems created by using kernelspace headers in userspace.
/usr/src/kernel/include should never *ever* be seen by anything except the
kernel and kernel-level drivers. Everything else should either have its
own headers, or use the libc's (which should have its own set defining the
appropriate types and structures needed for syscalls and ioctls).

This really isn't *that* difficult to get your head around.

Mo.

- -- 
Mo McKinlay
mmckinlay@gnu.org
- -------------------------------------------------------------------------
GnuPG/PGP Key: pub  1024D/76A275F9 2000-07-22





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjtQj7AACgkQRcGgB3aidfmTlACgmT1+c9JH0ShTp/roTgewMHq3
c70AoIyj/baePWnPgjI7TahB/VXl8BNy
=gKji
-----END PGP SIGNATURE-----

Re: __KERNEL__ removal

[Rick Hohensee]

>Jeff Garzik
>If there -must- be parts of the kernel that are visible to userspace,
>yes, we should separate them and make that separation obvious.  I would
>not call our current setup obvious :)


There are. -must-. Plan 9 minimizes them. It ain't POSIX, I'm guessing,
never having seen a POSIX in real life myself. I do happen to have K&R2
right here though. Hmmm, unistd.h is not in the 89 spec. Well of course
not. It's not C. You need need need that (which is why I did libsys.a),
and I think Plan 9 has a thing that lays out calling conventions for
syscalls, and some other things about the local CPU. Actually, Plan 9 lays
out lots of CPUs, being heterogenously distributed. That's where I get
dizzy, and start to wax unix-traditional. With all my twisted antics, I've
never cross-compiled anything. You also need ioctls for userland probably,
which Plan 9 either doesn't have or they actually figured out how to hide
them.

There's also a level below unistd.h maybe. A libcpu or something. Dono.

Rick Hohensee
		www.clienux.com

Re: __KERNEL__ removal

[Alexander Viro]

On Sat, 14 Jul 2001, Rick Hohensee wrote:

> >Jeff Garzik
> >If there -must- be parts of the kernel that are visible to userspace,
> >yes, we should separate them and make that separation obvious.  I would
> >not call our current setup obvious :)
> 
> 
> There are. -must-. Plan 9 minimizes them. It ain't POSIX, I'm guessing,

[snip]

FWIW, folks, proper context is: Rick just finished a trolling run on 9fans.
Rick, would you mind hauling your sorry ass somewhere else? You oscillations
between l-k and 9fans are getting tiresome. If you can't think of anything
that would be on-topic for either list - piss off and stop wasting the
bandwidth.

Re: __KERNEL__ removal

[Kai Henningsen]

jgarzik@mandrakesoft.com (Jeff Garzik)  wrote on 14.07.01 in <3B508D34.180A07A0@mandrakesoft.com>:

> If we want to avoid the retyping (which is IMHO the most clean
> separation for all cases, even if it involves drudgery) then separating
> out code into libc-only headers would be nice.

Not that I think anyone is going to take me up on this, judging from prior  
experience ...

... but if we are looking for a clean solution to types and constants that  
are needed to communicate between kernel and user space, IMO the thing to  
do is to define these in some sort of generic format, and have a tool to  
generate actual headers from that according to whatever kernel, libc or  
whoever wants to see. Possibly more than one tool as requirements differ.

That generic format *could* be a restricted form of C (restricted to only  
those features needed for this task), but need not be.

The tool in question is not all that difficult to write; *if* people think  
this is the right way to go (and agree on some of the necessary details),  
I could write it. In C, even, so it doesn't need extra tools.

MfG Kai

Re: __KERNEL__ removal

[Chris Wedgwood]

On Sun, Jul 15, 2001 at 01:53:00PM +0200, Kai Henningsen wrote:

    ... but if we are looking for a clean solution to types and
    constants that are needed to communicate between kernel and user
    space, IMO the thing to do is to define these in some sort of
    generic format, and have a tool to generate actual headers from
    that according to whatever kernel, libc or whoever wants to
    see. Possibly more than one tool as requirements differ.

Too complex, too hard... why not standard headers for the kernel
peoplem as that is the origin on the headers and helper comments for
others?


  --cw

Re: __KERNEL__ removal

[Horst von Brand]

kaih@khms.westfalen.de (Kai Henningsen) said:

[...]

> ... but if we are looking for a clean solution to types and constants that  
> are needed to communicate between kernel and user space, IMO the thing to  
> do is to define these in some sort of generic format, and have a tool to  
> generate actual headers from that according to whatever kernel, libc or  
> whoever wants to see. Possibly more than one tool as requirements differ.

Much easier, plain C, no special tools:

   include/linux/...
   include/asm/...
   include/glibc/...

where .../glibc/xyz.h contains the shared parts, and the others feel
free to include that as needed.

The real problem is that the interfaces _do_ change, as new syscalls,
ioctls, and constants show up (so "one set of .h for userland, cast in
stone for all eternity" won't _ever_ do), and that parts of the userland
are tightly bound to the kernel, and _need_ inside knowledge (strace, the
tools for manipulating modules, ...). Plus glibc and userland also
changes...
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: __KERNEL__ removal

[Chris Wedgwood]

On Sun, Jul 15, 2001 at 10:21:44AM -0400, Horst von Brand wrote:

    Much easier, plain C, no special tools:
    
       include/linux/...
       include/asm/...
       include/glibc/...
    
    where .../glibc/xyz.h contains the shared parts, and the others feel
    free to include that as needed.

Often lots of little files are a pain to edit compared to one larger
file.



  --cw