On Fri, Dec 02, 2005 at 09:42:09AM -0500, Steven M. Bellovin wrote:
> In message <mtuvey7wp9p.fsf@contents-vnder-pressvre.mit.edu>, "Nathan J. Willia
> ms" writes:
> >Elad Efrat <elad@NetBSD.org> writes:
> >
> >> We use sysctl(3) outside sysctl(8) a lot. Recent examples: using sysctl
> >> for reading inet/inet6/local PCBs and protocol statistics instead of
> >> using /dev/kmem; rpaulo@ even made trpt/trsp use sysctl, which means we
> >> don't have to give them the sgid kmem bit anymore.
> >
> >I object to those, too.
> >
> 
> I don't -- cleaning up kmem grovelers is a good idea.  Sysctl may not 
> be the best mechanism, but it's far from the worst.

What he said.  It occurs to me that the real problem here, though, is
essentially that existing device-node interfaces to this functionality
are _better_ in that they use the filesystem, thus the single consistent
object namespace that many of us desire (I know I'm not the only plan 9
fan around here) and have at least some access control (via ownership and
permissions) but _worse_ in that they allow unstructured access to,
much of the time, far too much underlying data.

A lot of the time, when this functionality migrates into sysctl namespace
the major benefit is that because of the way sysctl is implemented, it's
harder to implement bulk access to huge swaths of data than to actually
think through what must be visible or modifiable and implement access to
just that.  *That* is the real benefit: an explicitly typed interface
rather than the "read stuff and apply types to it yourself" interface
implemented via /dev, or the somewhat clumsy interfaces that try to
describe the underlying data using ioctl -- sysctl is better here, I
think, because it's *consistent* instead of a million underlying roll-
your-own takes on doing this with ioctl.

I still think the _names_ for these things belong in the filesystem and
that they should have filesystem permissions, but I am not sure we should
use standard filesystem system calls (not even ioctl) to operate on them.
I think that would pretty much give us the best of both worlds.  These are
*not* bytestreams and we should *not* treat them as such, as myriad bugs
and security holes have taught us again and again over time.

Thor