Hi,

I think so!  The reason that I agree rests on the
clustering effort that I am working on.  

In spite of the costliness of going though a syscall,
it forces all kernel interaction into a single point
which makes it easier when process migration works to
proxy syscalls to the node where the process was
started.  It also serves to allow globalization of
kernel resources so that they can be viewed by other
monitoring tools on remote machines.

I am totally in favor of this...

Andy Sporner

> -----Original Message-----
> From: Simon Burge [mailto:simonb@netbsd.org]
> Sent: Monday, June 12, 2000 10:25 AM
> To: tech-kern@netbsd.org
> Subject: sysctls for everything!
> 
> 
> After the recent updates for ps, top and ipcs to use sysctl()'s for
> accessing kernel data, would it be a "Good Thing(tm)" to apply this
> to the rest of the traditional kmem grovellers?  Here's a list of
> Makefiles that have BINGRP=kmem:
> 
> 	./sbin/ccdconfig/Makefile
> 	./sbin/dmesg/Makefile
> 	./usr.bin/fstat/Makefile
> 	./usr.bin/modstat/Makefile
> 	./usr.bin/netstat/Makefile
> 	./usr.bin/nfsstat/Makefile
> 	./usr.bin/systat/Makefile
> 	./usr.bin/vmstat/Makefile
> 	./usr.sbin/eeprom/Makefile
> 	./usr.sbin/ifmcstat/Makefile
> 	./usr.sbin/iostat/Makefile
> 	./usr.sbin/pstat/Makefile
> 	./usr.sbin/slstats/Makefile
> 	./usr.sbin/trpt/Makefile
> 	./usr.sbin/trsp/Makefile
> 
> Of these, it's even questionable (to me) whether ccdconfig should be
> setgid kmem.  All of dmesg, modstat, nfsstat, vmstat, eeprom, iostat,
> pstat, slstats, trpt and trsp all should be fairly mechanical 
> to convert
> to sysctl() due to the restricted (in terms of number, not 
> size) amount
> of data they access.  That leaves fstat, netstat, systat and 
> ifmcstat to
> look at in more detail...
> 
> Is this worth me pursuing further?
> 
> Simon.
>