From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 16 16:28:07 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9B4D16A4CE for ; Tue, 16 Nov 2004 16:28:07 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F54B43D54 for ; Tue, 16 Nov 2004 16:28:07 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 10941 invoked from network); 16 Nov 2004 16:28:07 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 16 Nov 2004 16:28:06 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iAGGRue5082873; Tue, 16 Nov 2004 11:28:02 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Tue, 16 Nov 2004 10:36:00 -0500 User-Agent: KMail/1.6.2 References: <20041115.231816.133541642.imp@bsdimp.com> <20041116.001446.66168349.imp@bsdimp.com> <4199B8A1.6080205@root.org> In-Reply-To: <4199B8A1.6080205@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411161036.01226.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org Subject: Re: Minor improvement to acpiconf X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2004 16:28:08 -0000 On Tuesday 16 November 2004 03:21 am, Nate Lawson wrote: > M. Warner Losh wrote: > > In message: <4199A260.3020001@root.org> > > > > Nate Lawson writes: > > : > acpifd = open(ACPIDEV, O_RDWR); > > : > if (acpifd == -1){ > > : > @@ -117,6 +117,17 @@ > > : > printf("Type:\t\t\t%s\n", battio.bif.type); > > : > printf("OEM info:\t\t%s\n", battio.bif.oeminfo); > > : > > > : > + if (ioctl(acpifd, ACPIIO_CMBAT_GET_BST, &battio) == -1) > > : > + err(EX_IOERR, "get battery info (%d) failed", num); > > : > + > > : > + if (battio.bst.state != ACPI_BATT_STAT_NOT_PRESENT) { > > : > > : Prefer positive logic. > > > > Most common path first is generally the logic I prefer... > > I thought there was a PRESENT define but apparently not. > > > : > + printf("State:\t\t\tPresent\n"); > > : > + printf("Rate:\t\t\t%d mWh\n", battio.bst.rate); > > : > + printf("Cap:\t\t\t%d mWh\n", battio.bst.cap); > > : > + printf("Volt:\t\t\t%d mV\n", battio.bst.volt); > > : > > : I agree with these except for a slight misgiving about "cap". That > > : information is already exported via sysctl and if we have to export the > > : same thing different ways, I think the interface is not optimal. > > > > Capacity isnt' exported via a sysctl. 'life' is, but it doesn't > > export anything more than a percentage. > > Life is derived from cap, but like I said above, I'm ok with it. > > > : In general, I'd like to move away from acpi-specific ioctls. There > > : should be just one way of getting the battery info and it shouldn't > > : refer to the underlying method names (_BST and _BIF) like the current > > : ones do. Mike made a good case for eliminating the dev_t entirely > > : since there is never any IO for acpi, it's all control traffic. Sysctl > > : seems more appropriate for that than creating a device that will never > > : see a read, write, or other access other than ioctl(). But this is a > > : complaint about the current design and the half-ioctl, half-sysctl > > : implementation. > > > > I'm not entirely sure I agree with a device needing read/write methods > > to be legit. Especially after I saw sysctl abused for the devinfo > > interface, which likely should have been read instead :-)... > > Looking in /dev, nearly all devices support IO. Only the .ctl or > .init/.lock devices are questionable. I think it makes sense for this > to be a criterion for using a dev_t. I think it would be handy personally to have /dev/batt0, etc. that both apm and acpi provide that are ways of getting info about the current battery state either via read(2) (which could always return a fixed-size status packet) or some kind of ioctl. I.e. a concept of an abstract battery driver with an interface implemented by both APM and ACPI and possibly other drivers in the future. (PowerMacs don't use ACPI AFAIK for example.) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org