Date: Mon, 01 Jun 1998 18:58:12 -0700 From: Mike Smith <mike@dingo.cdrom.com> To: dyson@FreeBSD.ORG Cc: mike@smith.net.au (Mike Smith), hackers@FreeBSD.ORG Subject: Re: kernfs/procfs questions... Message-ID: <199806020158.SAA02616@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 01 Jun 1998 21:25:24 CDT." <199806020225.VAA01608@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Mike Smith said: > > > > > > > I much prefer sysctl, being a convert from the kernfs camp. Procfs > > > is just bogus, not well thought out re-invention (IMO.) It seems that > > > the pseudo-MIB scheme of sysctl is nice. > > > > Personally, I like the basic idea (unified hierarchical namespace, > > method-based access, etc), but sysctl (and kernfs') implementation is > > unpleasantly inflexible. > > > Our sysctl is really easy to do all kinds of neat things. Try adding > a sysctl entry vs. a procfs (or kernfs) entry. In fact, I am about > to add about 50 sysctl's, and the amount of control that the sysctl > mechanism allows is staggering. Sysctl can provide both method > and variable access easily. To me it makes no sense to put something > like this under a mount point. If it needs to be globally exported, > make it an SNMP MIB. The plusses for putting things in the filesystem space are tough to ignore though: - Namespace traversal works properly - Access and traversal can be controlled using permissions - You can use unspecialised tools for access (eg. cat(1)) - Dynamism is easier than in the sysctl world I was musing over all this recently while I was trying to work out how best to export DMI information from various system components; specifically how to aggregate the output from the SMB BIOS fields, DMI-related drivers (eg. for the LM78, S.M.A.R.T. disk support etc) and other kernel components. To do this "well" we need to be able to add and remove entities from the space, and traverse it easily. These are things that the current sysctl implementation doesn't do well, and in conjunction with other things (eg. Linux support) I was wondering about other approaches. > > I'm also swayed in that we *do* need to follow the Linux lead at least > > to the point where we can run their binaries with a reasonable degree > > of success, so there's a little pressure on the border. > > > I would only believe so for the limited needs for Linux emulation. Note > that we do have kernfs, it is just in mothballs. I was a convert from > the FS methodology to the sysctl methodology, and with our much better > sysctl API (both in kernel and user) it is quite usable. (I had > to add some sysctl's under NetBSD, and it was very primitive.) Sure; but can't these sort of improvements be made to the methods for manipulating procfs nodes? What other drawbacks are there to the FS model? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806020158.SAA02616>