Quoting Poul-Henning Kamp <[EMAIL PROTECTED]> (from Wed, 17 Oct 2007
20:36:11 +0000):
In message <[EMAIL PROTECTED]>,
Alexander L
eidinger writes:
Quoting Poul-Henning Kamp <[EMAIL PROTECTED]> (from Tue, 16 Oct 2007 =20
17:32:40 +0000):
This discussion is growing too many branches, I have pruned to the
central core for now:
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.
This is what I think is the most fatal flaw in this design.
It is only an API for _some_ of the sensors in a system, and because
of that limitation, it invites people to try to shoehorn things
that do not belong there, into that subset.
Again, we don't need to put everything what OpenBSD puts into
hw.sensors into our hw.sensors. If you object to include the time
stuff into hw.sensors when we have an existing and good API for this,
I don't object. I even agree with you, as this would be a good
technical argument. But this is unrelated to the sensors framework
(the API). It is related how this API is used. Nothing prevents us to
come up with a policy how this API shall be used.
And for the "in a system" part, see my answer to Julian Elischer. You
are talking about something what I call "single-system sensor
framework" in the mail to him.
In this case, that puts code into the kernel that should under no
circumstances (have to) live there.
The timekeeping sensors is a prefect example of that, since March
2000 RFC2783 has defined the API for such stuff, but rather than
go and do things properly, somebody goes and implements DCF77
decoding in the kernel.
There was no modification to your time-stuff in FreeBSD. Instead of
complaining against the entire sensors framework, you could asks to
include a text somewhere, which tells that we are not interested to
add a sensor for the time stuff and why.
Kernel Architecture is just as much about preventing things as
enabling them.
Sensors, as here presented, fails both criteria: It doesn't do
enough for the relevant subject matter, and doesn't keep
irrelevant stuff abay.
Keeping the irrelevant stuff away means instantiating a policy.
Nothing prevents us from this. Feel free to start by contributing a
text which states that we don't want time sensors and why. For the
relevant things where you think it doesn't do enough, you should tell
us what you are talking about and why it is relevant. Maybe what you
want can be done without problems. As you haven't looked at the
framework itself (as you said you don't like the idea to an extend
that it is not even worth looking at it), you are in a weak position
to tell something can not be done with it (we've seen several times
that high level things you used to object against the sensors
framework integrate without problems into the sensors framework).
Bye,
Alexander.
--
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
The man who can smile when things go wrong has thought of
someone he can blame it on.
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
