cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults rc.conf src/etc/rc.d Makefile sensorsd src/lib/libc/gen sysctl.3 src/sbin/sysctl sysctl.8 sysctl.c src/share/man/man5 rc.conf.5 src/share/man/man9 Makefile sensor_attach.9 src/sys/conf f

[Constantine A. Murenin]

On 16/10/2007, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <20071016183311.lu97hbwzggsk4ow4 at webmail.leidinger.net>, Alexander L
> eidinger writes:
>
> >> Yes, that is the abstract argument, but the very same argument can
> >> be made for every other single kind of entity which consumes or
> >> produces bytes, from fingerprint readers to 9-track tape stations.
> >
> >Why do we have a common linked list API? It's easy enough to do it
> >again and again and again... We have it because we don't want to do it
> >again and again... And with the sensors API we gain something similar.
>
> There is a very big difference between <sys/queue.h> and sensors,
> in that <sys/queue.h> is not an external API, but a convenience
> tool for code to maintain its own data internally, whereas sensors
> is an API for exporting data.
>
> >It adds meta-data which can be used in an automated way. This is done
> >with a consistent and documented API. Sure, we can do it with sysctls
> >by hand, but see above.
>
> What exactly do you mean when you say "used in an automated way" ?
>
> Can I run some magic program and tell it "alert me if something is
> wrong" or do I have to write a tedious configuration file to explain
> what "something is wrong" would look like to the program ?

Yes, with ipmi(4), esm(4) etc on OpenBSD 4.2, sensorsd will
automatically alert you if something is wrong. No configuration is
required.

With lm(4)-style drivers, the situation is different -- some, rather
minimal, configuration will in fact be required.

> >It is not supposed to make the monitoring itself easier.
> >[...]
> >A human being still has to interprete the measurements. No doubts. But
> >with the framework you don't have to hunt down where to read the
> >sensor data, and how to name it. You can write a probe which takes
> >everything in the the sensors mib and let it produce names and values
> >for the probed things automatically.
>
> So the only problem sensors solves, is that it defines a single
> place in the sysctl tree, where you can find all sorts of non-random
> numbers, each of which comes with a piece of ascii text that isn't
> formatted in any consistent way ?
>
> I'd say, lets raise the bar several notches right here.
>
> How about we look at what is desirable from such a subsystem, and
> see what architecture that mandates ?
>
> Here are some things to think about:
>
> * Input only or input & output ?
>
>   Would it make sense to be able to control the fans or power
>   to various subsystems while we are at it ?

This is something that originally got me into all of this in 2005. I
currently have some crude hacks for lm(4) and the sensors framework
that allow me to set the fan-speed on one of my systems.

The problem with fan-control is the complexity it adds, most system
administrators aren't really interested in slowing their fans down
(although I am for my home servers), and, most importantly, many chips
feature so many various fan-controlling possibilities that a coherent
interface to accomplish such fan control isn't as easy as it may
sound. For example, many recent chips have at least three ways to
control the fan speed, by directly controlling the voltage, by doing
fan-speed cruise, by doing temperature-based cruise. Additionally,
there are selectors on which fan should be affected by which
temperature. Moreover, recent chips provide several levels of
temperature-based cruise. To complicate the matter, some chips are not
wired by the manufacturer to actually do any of the controlling, even
though they can in fact detect the speed and temperature just fine.
The list goes on and on.


> * It should be possible to implement a sensor in userland, so that
>   interface to external sensors is possible without forcing the
>   code into the kernel.  Think: Maxim/Dallas 1-Wire temperature
>   sensors and similar.

I am not certain about this, but OpenBSD already has support for 1-Wire sensors.


> * Metadata information in machine redable format:
>     - recommended, min and max poll rate
>     - Nominal value, quantization step and alarm limit(s)
>     - alarm transgression severity for system integrity
>     - sensorfailure severity for system integrity
>     - physical location of measured quantity
>     ...

OpenBSD has more than 50 drivers that utilise this sensor framework.
With most i2c and Super I/O chips, you simply don't have this
information, so why complicate the interface?

> * Event support ?
>     - enumeration, arrival and departure of sensors
>     - alarm transgressions
>     - sensor failure
>     ...

The arrival and departure could be implemented by sticking in some
devctl calls into sensordev_install and sensordev_deinstall. Out of
all sensor drivers in OpenBSD, I'm not aware of any single device that
has any reason to attach or detach any individual sensors after being
loaded. Effectively, there is an unsaid rule of not calling
sensor_attach or sensor_detach after sensordev_install has already
happened.

> * Interface and integration with IPMI, ACPI and similar.
>     Do any of these have a metadata format we can use ?

The sensors framework is integrated with ipmi(4) on OpenBSD. The
status field of each sensor is used to define whether each individual
sensor is performing within the specification.

>
> and probably a lot of other stuff I didn't think of right now...
>
> >Now... how much hardware out there supports IPMI, or
> >better... how much in production use doesn't use IPMI?
>
> But don't you think it would be better to have a subsystem that
> made it possible to use IPMI and ACPI, than to just say "Naa,
> that sucks, it must do, because we don't support it" ?
>
> >> Let me get this straight, you're telling me:
> >>
> >>      "I'm worried about this code running as root, so I'm putting
> >>      it in the kernel instead."
> >
> >You missed the point.
>
> No, I most certainly did not.
>
> By defining the sensor API (on top of sysctl) at the kernel/userland
> boundary you have decided that all sensor implementations must live
> in the kernel, there is no room in your architecture for sensors
> that live in userland.
>
> Effectively, you have elevated all sensor implementations to root++
> priviledge, even if they don't need any priviledge at all.
>
> I don't care much about who wrote the code or how trustworthy they
> are, that's a problem that can be fixed along the way.
>
> But I do care about taking away, by design, the choice of running
> at low priviledge from people who implement sensors.
>
> >> I repeat: The SoC interface is not the gateway to -current.
> >
> >It provides an idea in what people are interested in.
>
> Sure, lets list "Peace in the middle-east" on there, I'm sure people
> are interested :-)
>
> "People", whoever they are, are interested in anything that sounds
> fancy or flashy, but that doesn't mean that they can or will actually
> use it for anything if somebody produce it, and it certainly gives
> no guarantee that you will not shoot yourself in the foot along the
> way if you do so.
>
> People was very interested in UFS soft-updates and snapshots, but
> if we had paid more attention to what it did to the buf subsystem,
> we would probably have been a lot more cautious.  ZFS generates a
> lot of buzz, and similar concerns can, has been and should be raised
> about that.  (My answer to that on is to turn buf into a library
> function, so that each filesystem gets to screw only itself up).
>
> >And several
> >committers here in the thread also showed interest in this framework
> >(maybe not in the current implementation, but at least in the idea
> >behind it).
>
> Right, but if we didn't object, you had saddled us with this implementation,
> without any actual discussion about what exactly the idea behind it
> was and if that was the right idea for us.
>
> >Just because you do not see how such a framework can be
> >useful to you (so far I have the impression from your mails, that you
> >object to the idea of this framework),
>
> I *can* see why and how such a framework can be useful, that's why
> I'm objecting to this half-baked attempt at it.
>
> >> Ten years ago when we didn't have P4 and the _extensive_ infrastructure
> >> for making it easy for people to work out of the tree, we had to do
> >> stuff like that, but there is no excuse for it today.
> >
> >Nobody is perfect. There will always be some bugs when something is
> >committed to -current.
>
> Bugs, yes, and we have means to deal with them.
>
> But we should try much harder to avoid half-baked concepts and wrong
> architecture, because that is 10 times harder to fix than a plain
> bug is.
>
> >You don't talk about obvious problems here.
> >There's no destabilized system, there are no panics. You talk about
> >not using an underdocumented API and not using a generic framework for
> >creating tasks [...]
>
> Yes, it does appear to me that we are not on the same level of
> abstraction.
>
> I am indeed not talking about how many compiler warnings or style(9)
> infractions this code has.
>
> I'm talking about:
>   - if it actually solves a problem for us that we have.
>   - if if should solve more problems than it does right now.
>   - if it creates even more problems down the road.
>
> I'm talking about architecture, you're talking about code.