Date: Tue, 16 Nov 2004 15:12:34 -0800 From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-acpi@FreeBSD.org Subject: Re: Minor improvement to acpiconf Message-ID: <419A8962.9080804@root.org> In-Reply-To: <200411161036.01226.jhb@FreeBSD.org> References: <20041115.231816.133541642.imp@bsdimp.com> <20041116.001446.66168349.imp@bsdimp.com> <4199B8A1.6080205@root.org> <200411161036.01226.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > 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: >>>: 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.) I don't like this approach of adding more dev_t's. We already have a generic battery driver (see acpi_battery.c) which exports data via sysctl. It's acpi-specific in name only and could be generalized. Device entries in /dev were first created in Unix to handle IO. Later, ioctl() was added to handle the out-of-band configuration cases that just didn't fit read/write/seek. So creating new devices that only allow ioctl() access is the wrong way to go, I think. It never makes sense to write() to a battery. The cpufreq framework (which I'll polish and start posting as soon as I finish the major outstanding problem reports) is a good example of how this could work. It exports a single, unified interface via sysctl for adjusting CPU frequency. It also has a kobj interface for other kernel subsystems to control it. More than one control provider can register with it at once and it provides the union of all drivers' settings. It is not acpi-specific as well. Requests for settings from the kernel override user settings (i.e. for passive cooling). Anyway, while I agree the current interface sucks (amalgam of sysctl, multi-driver ioctls on /dev/acpi, and /dev/apm compatibility), I don't think adding more dev_t's is the right way to go on this. I'd rather see a uniform sysctl interface of hw.thermal.*, hw.battery.*, etc. and a mid-layer that takes registration requests from the various subsystems (apm, acpi, PowerPC Whatever) and presents a unified interface. Wrapping this interface in a user library is even better since it makes it possible to maintain an ABI for third-party apps (all of which currently use /dev/apm as the standard, BTW). My nightmare is that /dev/acpi becomes a new third-party standard, blech. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?419A8962.9080804>