Date: Mon, 15 Oct 2007 08:15:07 +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: <20071015081507.yi9t4ot8asg0wcw4@webmail.leidinger.net> In-Reply-To: <24712.1192384461@critter.freebsd.dk> References: <24712.1192384461@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Poul-Henning Kamp <phk@phk.freebsd.dk> (from Sun, 14 Oct 2007 =20 17:54:21 +0000): > My only beef is with the architecture of the sensors framework, and > as a consequence thereof, with the actual code as well. When I asked you about a proposal how a better architecture looks =20 like, you didn't came up with an explanation and you didn't came up =20 with a list of things which you think are bad in the sensors =20 framework. You also didn't respond to counterarguments from me. I don't think it is fair to make such a noise, without coming up with =20 technical facts. Note: I don't object to backing out the commit. But as this seems to =20 be on the desk of core@, I wait for their decision regarding this (as =20 it is self contained and doesn't interfere with other stuff, we don't =20 need to hurry). > In OpenBSD the sensors framework has already turned into a dumping > ground, and I have all reason to belive that we will see the same > under FreeBSD. It will be what we make out of this. > See for instance Marc Balmers presentation from EuroBSDcon2007 about > putting radio-timecode receivers under the sensors framework, or I don't see a need to port this part instead of using the existing =20 time-infrastructure in our kernel (and I don't have my fingers in the =20 time related code at all like you, so I hope other people think =20 similar). > listen to the various mumblings about putting RAID-controller status > under sensors framework. What's wrong with this? Currently each RAID driver has to come up with =20 his own way of displaying the RAID status. It's like saying that each =20 network driver has to implement/display the stuff you can see with =20 ifconfig in its own way, instead of using the proper network driver =20 interface for this. > IFF we want to have a general catch-all framework for representing > any oddball state, LED or measurement in the computer, then we want > it to be much better structured than the code we are discussing now. Again, please point out specific deficits, so that Constantine and =20 others can explain why it is like it is and may be able to come up =20 with improvements which address your concerns. > But it is not even clear to me that we want such a framework, it makes > much more sense to keep the various indicators, measurements and > other input in their respective subsystems. We're back to the old discussion... please have a look there. You =20 failed to respond with a technical counterargument when I presented =20 the reasons why a framework to export sensoric data out of the kernel =20 is good to have (in short: similar reason why we have a standard way =20 of exporting status data from the network interface to ifconfig). > And IFF we add such an amount of code to FreeBSD, we want to have it > properly integrate into our kernel, using our device discovery > and registration (newbus) and not probing random (i2c) busses willy > nilly. Could you please explain how you want to integrate devices with =20 newbus, which are only accessible via the i2c bus? Feel free to show =20 us example code for one of those of our drivers which access the i2c =20 bus, which already existed before this commit. 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 GREAT MOMENTS IN AMERICAN HISTORY (#17): On November 13, Felix Unger was asked to remove himself from his place of residence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071015081507.yi9t4ot8asg0wcw4>