Subject: Re: Mismatched enums in include files
To: David Laight <david@l8s.co.uk>
From: Andrew Brown <atatat@atatdot.net>
List: tech-kern
Date: 10/01/2003 00:07:27
>> >=>Should we have a KMEM_USER that makes some kernel structures visible to
>> >=>certain userland programs (ie the kmem grovellers) so that almost all
>> >=>the kernel internals can be inside _KERNEL?
>> 
>> i'm not sure that would scale well.  first of all, you'd have to know
>> what people are expecting to grovel and insert it all.  secondly, it
>> would have to be maintained going forward.  thirdly, someone would
>> invariably come along that wanted something you hadn't wrapped.
>
>IMHO much of what is exported from sys header files is kernel private.

well...on the one hand, it's "exported", so it's not "private".  take,
for example, the kqueue stuff.  the eventvar.h file is *specifically*
not installed because of what installing it implies.  now, i can't
imagine the contents of that file changing all that much, but who
knows?

>So no one should want to look at it at all.  If you define sysctl/ioctl
>interfaces to data then you should (unless you are IPF) manage to keep
>backwards compatibility when the kernel structes change.

much of that is easier said than done.  how, for example, would you
sysctl access to an arbitrary vm_map_entry?  or to an amap?  or the
amap data?  or an arbitrary vm_anon?

>To that end I'd expect that almost no kernel structures need be available
>to applications.  And there needs to be a good reason to export any of them.
>
>> >   On a broader note, is kmem grovelling really a supportable
>> >pattern going forward, or is it better off deprecated? It certainly
>> >seems to bring up more than its share of problems.
>
>I'd go for removing as many as possible.  Hiding the data structure
>definitions lets you find out who/what they are.

to be honest, i don't think there's all that much value to that.  if
someone needs a particular data structure, they'll figure out how to
get it, or punt and copy the definition at the time.  not providing
data definitions is particularly annoying when you need some piece of
a file, but you can't get it reasonably because something else in the
file demands to be undefined.  sys/mount.h and sys/syscallargs.h are
truly the most heinous abusers of "weird stuff" in my recent memory.

>> i imagine it will be around for a while longer...at least until you
>> can invoke sysctl in dead kernels.
>
>But the dump analysis tools are a class that do need access to kernel
>structures.  However that are very likely to be version dependant anyway.
>(not to mention that we don't have an obvious candidate that understands
>C header files....)

you see, what it comes down to is that there are "regular" programs
and "irregular" programs.  the regular ones don't care what you do,
for the most part, but the "irregular" ones tend to notice the tiniest
changes.  like lsof wrt procfs and kernfs.  now, clearly one cannot
expect to include an arbitrary file without getting errors, but its
typically possible to make those errors go away by including other
stuff.

in the recent case of procfs and kernfs (and lsof, which can be used
as a dump groveller because it was well-written), we ended up at a
place where you couldn't include two header files because they used
the same name for two totally different things.

that's bad.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."