Subject: Re: sysctlfs [was: Re: core file name format: diffs]
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 09/20/1999 12:24:01
[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.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B