From owner-freebsd-hackers Tue Jun 2 09:37:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA26657 for freebsd-hackers-outgoing; Tue, 2 Jun 1998 09:37:52 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles327.castles.com [208.214.167.27]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA26633; Tue, 2 Jun 1998 09:37:22 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id SAA02616; Mon, 1 Jun 1998 18:58:12 -0700 (PDT) Message-Id: <199806020158.SAA02616@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: dyson@FreeBSD.ORG cc: mike@smith.net.au (Mike Smith), hackers@FreeBSD.ORG Subject: Re: kernfs/procfs questions... In-reply-to: Your message of "Mon, 01 Jun 1998 21:25:24 CDT." <199806020225.VAA01608@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 18:58:12 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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