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. 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. 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
