Quoting Poul-Henning Kamp <[EMAIL PROTECTED]> (from Tue, 16 Oct 2007
17:32:40 +0000):
In message <[EMAIL PROTECTED]>,
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.
The idea behind is the same. Don't do a lot by hand what can be done
with less work with an API.
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" ?
You can write a probe for a monitoring system, which has a look at
hw.sensors and based upon the data it sees there can generate at least
<name> <type> <value> reports, without the need that the probe needs
to be changed to be able to handle sensors which wheren't seen before.
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 ?
It depends on the magic program and the sensor. As Constantine already
explained and you surely know, there are stupid sensors and there are
smart sensors.
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 ?
Hmmm... "desirable" is not the same as "useful" or "necessary". Let's
try to not overengineer this. Note: I also think as long as we try to
not prevent the framework to be able to handle specific things which
we think are desirable, the framework doesn't need to be able to
handle all from day one.
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 ?
Apart from what Constantine said:
Do you want to change the power of various subsystems? Isn't the
system supposed to do it itself in a sensible and automatic way? I
would say it depends. Most of the time I don't want to fight with
something like this in a production system (and AFAIK Intel tries to
do more and more themself regarding power control in their CPUs, as
they noticed that often the "messing around" with this is ...
suboptimal).
* 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 see hw.sensors as a interface to get the data from sensoric data
which is within control of the kernel into the userland. I don't think
about it as something where "sensor" includes status info from
userland applications. I fail to see where it is beneficial to put
data which isn't measured by something in the kernel (e.g. the fill
level of a database or any other value an userland program produces).
Could you please explain why it should be possible to feed such
userland data into the kernel?
* Metadata information in machine redable format:
- recommended, min and max poll rate
Typically the monitoring programs I know poll based upon a fixed rate.
The sensor framework caches already data, and it is up to the code
which puts the value into place to decide if the sensor has to be
queried again or not.
- Nominal value, quantization step and alarm limit(s)
Alarm limits normally are set in the monitoring applications I know
and depend upon various factors.
- alarm transgression severity for system integrity
How can a sensor know this? If it is about something which is in
active use, a violation of a specific value may be critical for the
entire system, but if it is just present in the system and not used at
all, crossing the same value may be not critical. In general this is a
policy decision which can not be solved by the person writting the
handover of this data to the sensor framework.
- sensorfailure severity for system integrity
Dito.
- physical location of measured quantity
Do you know monitoring programs which allow probes to submit this
information to the monitoring program? If not, why should the
framework allow to keep this information in the kernel when a file on
the system satisfies the same requirement?
...
So far the things you mentioned are better suited to be kept in the
userland, instead of in the kernel. A simple file which a specific
syntax would be enough to let a probe automatically match a specific
sensor with this metadata and let it transfer this to the monitoring
application (if the monitoring application is suited to accept this
kind of data).
* Event support ?
- enumeration, arrival and departure of sensors
- alarm transgressions
- sensor failure
...
* Interface and integration with IPMI, ACPI and similar.
Do any of these have a metadata format we can use ?
Constantine answered those already.
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" ?
I haven't said it doesn't support it, I told you already that Nate
didn't identify something in the sensors framework which prevents the
use of ACPI and the sensors framework, and Constantine already showed
how it integrates with IPMI.
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.
No, I didn't. I said (even last time when you first told us that you
don't like the sensors framework), that the sensors framework is
supposed to export data which lifes in the kernel to the userland. I
never said the sensors framework is supposed to be the one and only
way of getting status data from a running system. Userland status
belongs to userland programs. It would be nice to have a userland
framework which collects userland status, so that you don't have to
run around, and it may not be a bad idea that this userland framework
may collect also the data from the sensors framework (e.g. one plugin
to get all hw.sensors data, instead of multiple plugins to get all the
various states from the various places of a non-uniform status export
from kernel to userland). But here we talk about exporting data from
the kernel to the userland via an API, not about a userland framework
to collect status information (some people may say we already have
this with SNMP).
Effectively, you have elevated all sensor implementations to root++
priviledge, even if they don't need any priviledge at all.
No, I haven't, see above.
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'm not taking this away.
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.
You said you don't like the idea of an unified way of exporting sensor
data which lifes in the kernel to the userland. You didn't provide
technical arguments against such an API (I'm not taking lm.4 into
account ATM, as this was not your main objection). When the "People"
voted for this project, they voted for this idea, which seems to work
nice in OpenBSD. You failed so far to show that it doesn't work in
FreeBSD, while we've seen several examples where we get benefits from
it. I don't say the implementation is free of bugs, or can not be
improved, but you are not talking about code, you are talking about
the idea. You are slapping our fellow committers (I don't count myself
here) into the face, which voted in favour of this project. You are
doing the same with those people which didn't voted against this
project.
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.
I wouldn't have saddled us with the implementation. I would have maybe
saddled us with the API for the lifetime of one released branch... if
nobody would have improved it in the next 18 months (when HEAD is
branched). I don't think your very negatively sounding sentence above
is deserved. The people voting in the GSoC are supposed to reject
ideas which they identify as being outright bad. And for projects they
vote for, they have a look if it makes sense. If it doesn't make
sense, they don't vote for a project. The big disconnection between
FreeBSD and the SOC you are trying to put here, is not the case. I
agree that not everything which is produced in the soc deserves it's
way into CVS. But what gets rejected to far is stuff which proved
during the soc to be not usable. Either because the architecture
doesn't fit, like with the pluggable disk schedulers when you
introduced GEOM and the project wasn't usable anymore, or because the
student missed the goal, or when the goal was achieved but the
implementation was a cruel, or when we noticed that the project needs
complete rearchitecture because the initial design doesn't fit.
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.
Now you sound differently than before. Before you said you don't like
the idea of such a framework at all. Some of the points you bring on
the table above look overengineered to me (I pointed them out). And so
far I wasn't able to identify a point there, which the sensors
framework prevents to implement. I also want to point out that so far
the goal was to do what is needed and evolutionary improve the
architecture/implementation, instead of trying to produce a big thing
with bells, whistles, trumpets and whatever (in Germany we call this
"eierlegendewollmichsau"). We all know that overengineered projects
typically fail, and that the evolutionary behavior in OpenSource
software produces very good results (e.g., SMP in 4.x was very good
for this time, and now as we have "more SMP" and raised expectations
we morphed into something better). Some of the things you want to have
for sensors looks nice. Some of this nice stuff doesn't belong into
the kernel. And I haven't seen something which can not be done with
the sensors framework in a next step. So far the sensors framework
allows to provide features we don't have in RELENG_x.
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.
Feel free to point out wrong architecture. Regarding the half-baked
part... so far Constantine already showed what is possible to do from
the list you came up with. I still think you are fighting against the
framework based mostly upon feelings, and not based upon technical
facts.
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.
gcc 4 introduced new warnings. Without compiling this with -Werror on
e.g. RELENG_6 with gcc 3, I don't think you should talk about compiler
warnings at the moment, as the kernel is on a similar level (in case
we don't compile with -Werror anymore). Regarding style(9) Constantine
made several commits in p4 during the soc.
I'm talking about:
- if it actually solves a problem for us that we have.
Yes.
- if if should solve more problems than it does right now.
As you have seen it already does more than you think it is able to do.
- if it creates even more problems down the road.
Have you identified some problems?
I'm talking about architecture, you're talking about code.
Wrong. I never said the code is without the possibility to improve it
or that it is free of flaws. I'm talking about your behavior of
rejecting the idea (not even the architecture, but the idea) of the
sensors framework without accepting that other people see a benefit in
such a framework and calling it crap without comming up with technical
reasons. I'm also talking about the idea of the framework and what it
is supposed to do whiel you say that you don't like the idea. I may
also have talked about parts of the code, but it is wrong to say that
I focus on the code. And I'm also the wrong person to talk about the
code, Constantine is the person to talk with if it is about the code.
Bye,
Alexander.
--
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
No one can feel as helpless as the owner of a sick goldfish.
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
