[ 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      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>