Date: Thu, 18 Oct 2007 09:11:34 +0200 From: Alexander Leidinger <netchild@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Wilko Bulte <wb@freebie.xs4all.nl>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: 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 ... Message-ID: <20071018091134.jzo7m88374ow00c8@webmail.leidinger.net> In-Reply-To: <52235.1192653371@critter.freebsd.dk> References: <52235.1192653371@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Poul-Henning Kamp <phk@phk.freebsd.dk> (from Wed, 17 Oct 2007 20:36:11 +0000): > In message <20071017160440.b6fd00xs6cog888g@webmail.leidinger.net>, > Alexander L > eidinger writes: >> Quoting Poul-Henning Kamp <phk@phk.freebsd.dk> (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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071018091134.jzo7m88374ow00c8>