[quotes from at least three different people here]

> I'd really love to see a filesystem-frontend to sysctl.

> An extention to kernfs ?

> Ah, that means that the info will be on three places then ?  I.E. the
> code in kernel, symbolic names in sysctl and the same symbolic names
> in kernfs ?
> 
> This really needs to be though out.  IMHO changing sysctl(2) to
> accept string params would be the right thing to do.

To be pedantic, sysctl(2) doesn't exist; it's sysctl(3) or __sysctl(2),
though I don't think there's any manpage for the latter.

Changing sysctl() to take strings would really complicate a lot of
code, it seems to me.  As for sysctlfs stuff, this new proc mib would
mean duplicating a lot of what procfs does.  (Could this be turned into
common code, perhaps?)

I've been pondering a sysctlfs for quite a while, though I too have
never started doing anything about it.  I'm not quite sure whether I'd
rather see "/sysctl/1/6" or "/sysctl/kern/maxproc".  The latter has
i18n problems, but the same is true of kernfs and procfs as they stand,
as well as many other interfaces.  There's also the point that
sysctl(3) handles a lot of stuff entirely in userland, so either
sysctlfs would have to move that into the kernel or have an interface
to allow userland to handle it.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B