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 files ...
phk at phk.freebsd.dk
Mon Oct 15 12:52:11 PDT 2007
In message <20071015210909.1b6b693b at deskjail>, Alexander Leidinger writes:
>Quoting "Poul-Henning Kamp" <phk at phk.freebsd.dk> (Mon, 15 Oct 2007 15:01:47 +0000):
>> >And I responded that we need to have a way to export data from the
>> >kernel to userland in an unified way.
>> I can't seem to find the supposed requirement for unification here,
>You didn't comment on what I wrote about reducing the work of
>reinventing a way to export the data we want to export again and again
>and again and again...
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.
My beef with this code is that it unifies a lot of non-alike
measurements and indications in a new, and pretty bogus IMO, api,
but adding no value above a plain old sysctl while doing so.
>> and in fact, it is exactly that a lot of crap gets bundled up
>> under the wildcard term of "sensor" that I object to.
>Exporting temperature readings / voltage measurement, system status is
Actually it is, if it can be done as well (or better) from userland
by exporting the underlying communications paths.
>And when you write some monitoring probes in a large server
>farm, you don't want to hunt down every interesting data value in a lot
Ahh, so this brings me to the next problem with sensors.
If by "monitoring" you mean "plot MRTG graphs", then I guess sensors
could possibly make sense, although, I'd have to point out that all
that can be done just as well from ports/sysutils/whatever.
But if you're talking real world monitoring, then sensors are
pointless, because there is no way to derive necessary machine
readable contextual information, such as alarm limits, resolution,
calibration constants, hysteresis, polling periods etc.
Or, for that matter, machine-readable information about what is
actually being measured and where it is being measured and what it
There are frameworks for doing that sort of stuff in professional
server hardware, but since OpenBSD doesn't support those, IPMI,
ACPI etc, they have come up with this VAX-mentality junkheap instead.
>> >I already told you last time
>> >that the current way (access to the i2c or smbus) needs more access
>> >rights than using the userland parts of the sensors framework.
>> More rights than what exactly ?
>One popular userland temperature/voltage reading tool (as it supports a
>lot of popular devices) is mbmon. It is currently a SUID root
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."
Can anybody here spot the logic flaw of this argument ?
Right, I thought so. Lets pretend you didn't say that.
>> No, I have yet to see why we need this framework.
>Several committers which voted for this project in the soc webinterface
>seem to think otherwise, else they wouldn't have voted for it.
I repeat: The SoC interface is not the gateway to -current.
>> >> C) How it integrates into FreeBSD and for the places where
>> >> it does not (newbus ?) why it doesn't.
>We're discussing it right now. And I was willing to discuss this even
>back when you talked about it the first time.
It should have been dicussed and fixed before being committed to
-current. Current is not where you start, it is where you end, these
kind of things are not details to be hashed out in CVS.
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.
>> >The code we have currently doesn't harm the system, [...]
>> This is where I disagree: it does harm the system.
>> It dumps a load of badly thought out code into our source tree, and
>> that will effectively be in the way of any well thought out solution
>> that might ever appear.
>> This stuff should be backed out, and forced to live outside the tree
>> until it satisfies our quality and architectural requirements.
>How does this compare to your attitude of bringing stuff into the tree
>and letting other people fixup collateral damage in the past? But I
>drift away from the topic... so back to the sensors framework.
It does not compare, please answer the question instead of trying
to insult me, because you're no good at it. I have been insulted
by people who were far better insulters than you, and you didn't
even tickle my funny bone.
(If you want to enter into a discussion of the changes in our development
methodologies over the last 15 years, and the difference between
peripheral optional bits and pieces, versus heavy-duty-your-system-wont-
boot-without-it infrastructure, and why some code succeeds and some
fails, I'll be happy to take that discussion. It's a very interesting
topic to which I have devoted considerable amounts of time, but we
should discuss that in a different thread, not this one.)
>To be able to address our quality and architectural requirements, we
>need first to know which quality and architectural requirements are
>violated by which part of the code in question. As you seem to have
>identified them, would you please so kind and share your concrete
Would you be so kind as to read the emails I've sent you ? Maybe
this time expending some effort to understand what people tell you in
them, rather than pretending they contained nothing ?
>> Forcing it to stay out of -current, means that the motivational
>> pressure is on the people who thing we badly need this featureset,
>> and gives them reason to improve it.
>> Leaving it in the tree, is the sure fire way for it to become an
>> unmaintained lump of code that slowly rots away.
>You did a psycho-analysis of Constantine so that you are able to tell
>that he doesn't fix the issues while he agreed to improve the framework?
No, it's far worse.
I have 15 years of experience with this kind of code being slammed
into the tree in an unfinished and badly thought out shape.
And I have wasted far more time cleaning it up afterwards, than you
or constantine will have spent on FreeBSD five years from now.
I suspect I still hoover somewhere near the top of the cvs/sys
commitstats that peter used to maintain, I didn't get there by
accident, and I'll be damned if I let people force me or anybody
else to suffer through that amount of cleanups again.
>> >You object to the current implementation because you think it is bad.
>Great, so you know specific issues and can tell us about them (again,
>other people pointed out specific stuff already and also pointed to
>things which help to let Constantine improve the issues which where
The implementation is bad because the fundamental idea is bad. It
cannot be helped IMO.
>> The solution to that is to remove it from -current, let it live in
>> P4 until such time that it passes muster in a review on arch@ which
>> gives relevant people a chance to study and comment on it.
>> >You don't go to court and tell someone is guilty and then the person
>> >has to prove he/she is not guilty.
>> No, I go to court, get a prelimnary injunction so that he is forced
>> to stop while a proper review is carried out.
>And the judge first listens to your arguments and makes up his mind
>before he issues a preliminary injunction.
I seem to recall that quite a number of people have objected and
several very senior developers have said "back out" already now.
Your resistance to subtle clues would make you an execellent candidate
for the US presidency, but it makes you a very poor FreeBSD committer.
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the cvs-src