On Sat, Sep 27, 2003 at 04:44:02PM -0400, Gary Duzan wrote:
>In Message <20030927184820.W4342@snowdrop.l8s.co.uk> ,
>   David Laight <david@l8s.co.uk> wrote:
>
>=>> yes, lsof does define _KERNEL to get to that stuff, and a lot of other
>=>> stuff, too.  drat.  that means i have to go fix lsof again.  well, at
>=>> least this is all happening close together temporally...
>=>
>=>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.

>   In the case of lsof, at least, doing proper sysctls for the
>information of interest would probably be best, though a bit time
>consuming. It would take care of the LOCKDEBUG problem, too.

doing sysctls (or something like that) would be rather nice.  have a
look at what hp did.

	http://docs.hp.com/hpux/onlinedocs/os/11i/pstat_whitepaper.pdf

>   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 imagine it will be around for a while longer...at least until you
can invoke sysctl in dead kernels.

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