From owner-freebsd-hackers Thu Jun 4 13:13:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA25015 for freebsd-hackers-outgoing; Thu, 4 Jun 1998 13:13:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA24918 for ; Thu, 4 Jun 1998 13:13:14 -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 MAA01291; Thu, 4 Jun 1998 12:08:28 -0700 (PDT) Message-Id: <199806041908.MAA01291@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Matthew Jacob cc: freebsd-hackers@FreeBSD.ORG, tech-kern@NetBSD.ORG, woods@zeus.leitch.com Subject: Re: hardware monitor device drivers / kernel support (eg. LM78) In-reply-to: Your message of "Thu, 04 Jun 1998 09:18:48 PDT." <3576C8E8.AB32C5@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jun 1998 12:08:28 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith wrote: > > 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). That'd be more like "and"; there are a lot of words there. 8) > > 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. Understood; there's also a lot of platforms where there are no BIOS services per se. I think I should have been clearer there insofar as the point I was attempting to make was that there seems to be no winning standard for accessing environmental data. > > - 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. Yes; and dynamism includes boot-time as well as run-time. This is prettymuch a given. > 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. No kidding. I have been watching the DMTF for over 12 months now, and they show no signs of flagging. It may have something to do with the undeniable appeal that "lower TCO" and "increased accountability" has to people in the managerial arena. I feel that it's important not to lose sight of this, as failure to perform in this area will instantly disqualify you from many major markets. > 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. The preferred method for moving data out of kernel space is likely to vary by platform; even if you were to standardise on the in-kernel side of that interface it would be advantageous, eg. +-------+-------+-------+-------+ parameter access API | prm 1 | prm 2 | prm 3 | prm 4 | +-------+-------+-------+-------+ parameter access lib | platform dependant | +===============================+ parameter im/export | platform dependant | +-------------------------------+ parameter abstraction | platform dependant | +-------+-------+-------+-------+ parameter collection | dev 1 | dev 2 | dev 3 | dev 4 | +-------+-------+-------+-------+ I/O abstraction | platform/machine dependant | +-------+-------+-------+-------+ hardware | 1 | 2 | 3 | 4 | +-------+-------+-------+-------+ > 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. Yup. > b) The actual kinds of data sources can be ad hoc and don't > *have* to present unified information objects- the implib > can translate. Yes, although I would tend to expect that the given platforms are likely to want a unified mechanism for parameter export. > 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... 8) > 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! Not unreasonable. I don't think that any of this is going to happen terribly fast... -- \\ 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