Minor improvement to acpiconf
nate at root.org
Tue Nov 16 15:12:41 PST 2004
John Baldwin wrote:
> On Tuesday 16 November 2004 03:21 am, Nate Lawson wrote:
>>M. Warner Losh wrote:
>>>In message: <4199A260.3020001 at root.org>
>>> Nate Lawson <nate at 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
>>>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.
More information about the freebsd-acpi