From owner-freebsd-hackers Thu Jun 4 09:19:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06713 for freebsd-hackers-outgoing; Thu, 4 Jun 1998 09:19:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mauswerks.net (root@ns.mauswerks.com [204.152.96.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA06684 for ; Thu, 4 Jun 1998 09:19:32 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (root@gw100.feral.com [192.67.166.129]) by ns.mauswerks.net (8.8.0/8.6.9) with ESMTP id JAA24573; Thu, 4 Jun 1998 09:20:25 -0700 Received: from feral-gw (mjacob@gw100.feral.com [192.67.166.129]) by feral.com (8.8.6/8.8.6) with SMTP id JAA10993; Thu, 4 Jun 1998 09:18:48 -0700 Message-ID: <3576C8E8.AB32C5@feral.com> Date: Thu, 04 Jun 1998 09:18:48 -0700 From: Matthew Jacob Organization: Feral Software X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: Mike Smith CC: freebsd-hackers@FreeBSD.ORG, port-i386@NetBSD.ORG, tech-kern@NetBSD.ORG, woods@zeus.leitch.com Subject: Re: hardware monitor device drivers / kernel support (eg. LM78) References: <199806032134.OAA01436@dingo.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > I have on my middle burner a environmental services driver to port > > into both NetBSD and FreeBSD (and possibly linux). It will manage > > both SES (SCSI Environmental Services) and SAF-TE (see http://www.safte.org). > > Environmental and power control issues are becoming big business it > seems. Starting at the top with DMI (www.dmtf.org) and going down, > there's a large model forming. Do you plan to work within this, or do > you have an alternative framework in mind? I hadn't gotten that far- but I hadn't charged ahead just for the reason that I know that this is grown very big very fast. The DTMF model may not address some large server system issues- I don't know it very well (I'll read the specs today or tomorrow). > The I2C thing has been somewhat of an issue for me - many PC > motherboards (eg. everything with a PII onboard) have an I2C variant > (SMB). Unfortunately, the SMB BIOS doesn't seem to be widely > implemented, so there's no precedent for a set of primitive bus > services there (only the SMB I/O in the PIIX4). There's a lot I2C supprt that is not BIOS managed. > > For your parametric retrieval, depending on the messaging style you > might want to consider: > > - DEVFS node (not really portable outside FreeBSD AFAIK). Yup. > - 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. > - socket, cf. PF_ROUTE. This would involve creating a new event > reporting facility (PF_EVENT) and assorted infrastructure. > > It sounds like you're looking at two of a set of environmental services > (others eg. S.M.A.R.T.) which should be coordinated within a unified > framework. DMI offers this, although at the cost of some (!) extra > complexity. > > I'd be very interested to hear others' opinions on the relevance of DMI > and the work of the DMTF. Note especially the advanced state of DMI : > SNMP mapping techniques they recommend, if you are concerned about SNMP > interoperability. 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. 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. One of the implications then of doing this is that we don't: a) have to agree how to collect the information (from platform to platform)- that's for that platform's implib to deal with. b) The actual kinds of data sources can be ad hoc and don't *have* to present unified information objects- the implib can translate. Hmmm- I think I've argued myself around to *not* having a unified set of services at a lower level- typically device driver writer's reaction- punt it to a higer level... I'll mull over all of this a bit more and see whether I can propose something more- but really, truly, I'll be putting in the SES/SAF-TE driver very soon- I need it for some other projects! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message