From owner-freebsd-hackers Fri Jan 12 11: 1:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D063737B401 for ; Fri, 12 Jan 2001 11:01:36 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0CJ0T134955; Fri, 12 Jan 2001 11:00:29 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010113034023K.iwasaki@jp.FreeBSD.org> Date: Fri, 12 Jan 2001 11:01:10 -0800 (PST) From: John Baldwin To: Mitsuru IWASAKI Subject: Re: CFR: Generalized power-management interface Cc: hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message