From owner-freebsd-hackers Thu Jun 4 12:04:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA11106 for freebsd-hackers-outgoing; Thu, 4 Jun 1998 12:04:30 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA10919 for ; Thu, 4 Jun 1998 12:04:06 -0700 (PDT) (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id PAA14391; Thu, 4 Jun 1998 15:03:17 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id PAA01231; Thu, 4 Jun 1998 15:03:25 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id PAA27862; Thu, 4 Jun 1998 15:03:25 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Thu, 4 Jun 1998 15:03:25 -0400 (EDT) Message-Id: <199806041903.PAA27862@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-hackers@FreeBSD.ORG, tech-kern@NetBSD.ORG Subject: Re: hardware monitor device drivers / kernel support (eg. LM78) In-Reply-To: Matthew Jacob's message of "Thu, June 4, 1998 09:18:48 -0700" regarding "Re: hardware monitor device drivers / kernel support (eg. LM78)" id <3576C8E8.AB32C5@feral.com> References: <199806032134.OAA01436@dingo.cdrom.com> <3576C8E8.AB32C5@feral.com> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: freebsd-hackers@FreeBSD.ORG, tech-kern@NetBSD.ORG, woods@zeus.leitch.com (Greg A. Woods) Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ On Thu, June 4, 1998 at 09:18:48 (-0700), Matthew Jacob wrote: ] > Subject: Re: hardware monitor device drivers / kernel support (eg. LM78) > > > - sysctl node (may be problematic if you want to dynamically create > > nodes at runtime, unless you handle your own traversal). > > We have to plan for dynamic- if you support dynamic addition/deletion > of devices, you must also plan for devices that manage environmental > data as well. Let's say we handle (as we should and will) SCSI devices > dynamically attaching and detaching- well, there you'll have > environmental devices coming and going. *If* it's possible to come up with a high enough (but not too high!) level of abstraction for hardware/environmental monitoring (i.e. a real MIB-style definition that's not device or "vendor" or platform specific!), then it should be possible to have the nodes available at all times, even if its not 100% enabled and usable. > Yes- this may be the way to go, although I had a more practical and > immediate concern about how to get support in, even partial support, > as quickly as possible with an eventual goal to have a unified management > schema. Clearly this thing is much bigger than I thought. My goal is *definitely* to get minimal support in and working fast. I'd like to start down a path that would be useful for a much more complete hardware and environmental management subsystem though. > I would prefer an ioctl interface since that eases porting across all > the unix variants (they all have ioctl- only FreeBSD has DEVFS, only > *BSD has sysctl, only Linux has that sexy procfs way to get info)- but > this may in fact be not that important if you add an additional user > layer that handles the collection of data and presents objects upward. > The amount of data involved is small, and the real time constraints > are not onerous. Sysctl is really just a more structured form of ioctl interface from a design perspective, and of course it's not really tied to any one hardware device. If you conceptually replace the '.'s in the sysctl naming scheme with '/'s, and mount it as a filesystem then suddenly your access options open up to the infinite. Even now that I have a tiny inkling of what DEVFS is, I still don't see what it has to do with all of this -- it seems like something on the side of the device driver structure, not a primary method of abstraction for monitoring of external parameters, setting alarm limits, etc. It sounds kinda cool, but as you say it's unique to FreeBSD. All the *BSDs have kernfs. The linux procfs is essentially a merge of features from the *BSD procfs and kernfs, with even more features added on as well. You can even do kernfs in AT&T SysVr3.2, and certainly on SysVr4. Virtual filesystems are possibly even an older concept than sysctl, and certainly far more widely spread (and IMNSHO far more elegant and useful). The most important benefit of virtual fileystems is their ability to easily support very good backward and forward compatability, something that's impossible with ioctl(2) and hard with sysctl(3) [though perhaps not quite impossible with FreeBSD's __sysctl(2)]. -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message