In article <20030930142537.Q548@snowdrop.l8s.co.uk>,
David Laight <david@l8s.co.uk> wrote:
>> >=>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.

That is all well and done for interfaces and applications that are mature,
popular, and well understood. As kernel API's change and improve, or for
applications that did not exist before, getting ``unauthorized'' access
to the kernel headers by defining _KERNEL is fine, as it has always been.
When those applications become mainstream, implementing sysctl/ioctl/or
even open/read/write/ interfaces as appropriate is the way to go.

christos