> >=>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.
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.

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.

> 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....)

	David

-- 
David Laight: david@l8s.co.uk