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 20:36:11 +0000): > In message <20071017160440.b6fd00xs6cog888g@webmail.leidinger.net>, =20 > Alexander L > eidinger writes: >> Quoting Poul-Henning Kamp <phk@phk.freebsd.dk> (from Tue, 16 Oct 2007 =3D= 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 =20 hw.sensors into our hw.sensors. If you object to include the time =20 stuff into hw.sensors when we have an existing and good API for this, =20 I don't object. I even agree with you, as this would be a good =20 technical argument. But this is unrelated to the sensors framework =20 (the API). It is related how this API is used. Nothing prevents us to =20 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 =20 are talking about something what I call "single-system sensor =20 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 =20 complaining against the entire sensors framework, you could asks to =20 include a text somewhere, which tells that we are not interested to =20 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. =20 Nothing prevents us from this. Feel free to start by contributing a =20 text which states that we don't want time sensors and why. For the =20 relevant things where you think it doesn't do enough, you should tell =20 us what you are talking about and why it is relevant. Maybe what you =20 want can be done without problems. As you haven't looked at the =20 framework itself (as you said you don't like the idea to an extend =20 that it is not even worth looking at it), you are in a weak position =20 to tell something can not be done with it (we've seen several times =20 that high level things you used to object against the sensors =20 framework integrate without problems into the sensors framework). Bye, Alexander. --=20 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 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>