From owner-freebsd-hackers Fri Jan 12 11: 5:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B6CD037B404; Fri, 12 Jan 2001 11:05:02 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA27974; Fri, 12 Jan 2001 11:05:03 -0800 Date: Fri, 12 Jan 2001 11:04:59 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: Mitsuru IWASAKI , hackers@FreeBSD.ORG Subject: Re: CFR: Generalized power-management interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If we're going to talk about 'health' for a machine and it's components, it should tie in with the SES/SAF-TE driver (for SCSI/FibreChannel). > > On 12-Jan-01 Mitsuru IWASAKI wrote: > > Hi, > > > >> > I'll get device major number for /dev/power and commit them within a > >> > few days if no objection. > >> > >> One thing that I was talking about with Mike Smith is that perhaps instead > >> of > >> having a /dev/power just for power management stuff we should be a bit more > >> generic and have a /dev/health used for anything related to the machine's > >> "health"? This could include power management, thermal zones, etc. BTW, > >> the > > > > I'm not sure if /dev/health is better but I think having common API > > for the machine's health is good thing. How about having /dev/power, > > /dev/thermal or whatever related with machine's health as abstracted > > layers, and creating API libraries for each subsystems like libpower, > > then providing libhealth as full-set API for the applications? > > It was just an idea to think about is all. :) However you do it will probably > be fine. I'm not really working on this code enough to make too many > suggestions right now. :) > > >> battery status doesn't work on my laptop unfortunately, but that is because > >> I > >> have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. > >> :( > > > > Is that related with embedded controller too? > > Yes. I need to figure out how ACPI_DEBUG works so I can dimp debugging info > and find out where it hangs when I don't disable the SIO_ controller. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message