Date: Tue, 16 Nov 2004 10:36:00 -0500 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-acpi@FreeBSD.org Cc: acpi@FreeBSD.org Subject: Re: Minor improvement to acpiconf Message-ID: <200411161036.01226.jhb@FreeBSD.org> In-Reply-To: <4199B8A1.6080205@root.org> References: <20041115.231816.133541642.imp@bsdimp.com> <20041116.001446.66168349.imp@bsdimp.com> <4199B8A1.6080205@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 16 November 2004 03:21 am, Nate Lawson wrote:
> M. Warner Losh wrote:
> > In message: <4199A260.3020001@root.org>
> >
> > Nate Lawson <nate@root.org> 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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411161036.01226.jhb>