Date: Mon, 15 Oct 2007 15:24:08 +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: <20071015152408.10kvgtog6cooc4wc@webmail.leidinger.net> In-Reply-To: <44701.1192432387@critter.freebsd.dk> References: <44701.1192432387@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Poul-Henning Kamp <phk@phk.freebsd.dk> (from Mon, 15 Oct 2007 =20 07:13:07 +0000): > In message <20071015081507.yi9t4ot8asg0wcw4@webmail.leidinger.net>, =20 > Alexander Leidinger writes: >> Quoting Poul-Henning Kamp <phk@phk.freebsd.dk> (from Sun, 14 Oct 2007 >> 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 >> like, you didn't came up with an explanation and you didn't came up >> with a list of things which you think are bad in the sensors >> framework. You also didn't respond to counterarguments from me. >> >> [...] >> >> Could you please explain how you want to integrate devices with >> newbus, which are only accessible via the i2c bus? Feel free to show >> us example code for one of those of our drivers which access the i2c >> bus, which already existed before this commit. > > So, lets see how that works: > > =09I propose that we write our own C/C++ compiler in perl. > > =09You object to that. > > =09Then I tell you: Now YOU have to write the compiler. > > No, I didn't think so either :-) Come on Poul, you know that the response to such an objection would be =20 to ask for reasons for the objection and the constructive continuation =20 would be to point out weaknesses in an understandable way (and =20 pointing out better ways if known) by the person with the objections. > I have several times in the past pointed out why it is a very bad > idea to add a unstructured dumping ground to the kernel, and why > it is bad to stick code in the kernel that can easier live in > userland. And I responded that we need to have a way to export data from the =20 kernel to userland in an unified way. No need to replicate a lot of =20 code in a lot of places to export the data. When the data is out of =20 the kernel in an unified way, one can do a lot of things with it in an =20 automated way (e.g., use it in nagios or cacti, or whatever), but so =20 far we don't have a framework for this. I don't say the sensors framework can not be improved (in fact we got =20 some improvement suggestions) or that I know more than you, but I =20 think it doesn't deserve that much noise as is happening here currently. Regarding your argument to move some parts into the userland (if not, =20 please point out what you are talking about)... I assume you are still =20 talking about the temperature sensors. I already told you last time =20 that the current way (access to the i2c or smbus) needs more access =20 rights than using the userland parts of the sensors framework. I can =20 not remember that you objected to this security improvement or =20 provided technical arguments which made this point obsolete. Feel free =20 to point me to a corresponding mail I may have missed. Feel also free =20 to point out where Constantine or me aborted discussing things with =20 you, so far I remember that you didn't follow up on our last responses =20 to what you wrote the last time we talked about the sensors framework. > Right now, the people who advocate importing the OpenBSD sensor > framework need to tell us, in a coherent architecture document: > > A) Why we need it Already told here and in the past. I haven't seen any word from you =20 that those reasons are not enough for you (and why). > B) Why so much of it ends in the kernel If you talk about the temperature/voltage sensors: Already told here =20 and in the past. I haven't seen any word from you that those reasons =20 are not enough for you (and why). > C) How it integrates into FreeBSD and for the places where > it does not (newbus ?) why it doesn't. The improvement suggestions we got from someone else (private mail) =20 deal with newbus and provide an example. The suggestions also talk =20 about using taskqueue(9) and some other things. This critique is what =20 I call "constructive". From you I've only seen hand waving and whistle =20 blowing so far. Can we please go to a constructive way of criticism? Constantine agreed to improve what we have. So far the code is not =20 scheduled to go into 7.0 (and based upon the constructive suggestions =20 we got so far the code we have currently will not be in 7.0 for sure). =20 The code we have currently doesn't harm the system, provides =20 additional features, is far from seeing a release ATM (8.0 is about 18 =20 months away, plenty of time to remove unwanted parts), and the primary =20 author agreed to work on improvements. From an userlevel point of view the current offering is not bad. We =20 get an unified way of getting status information in a safe way. From a =20 developer which doesn't work on the framework point of view, the =20 kernel compiles and is not destabilized by the commit. The framework =20 is also not spread over the entire kernel. You object to the current implementation because you think it is bad. =20 Ok, I don't object to your objection. All I ask is to put the cards on =20 the table so that we can find a way forward. A way which gives the =20 users the new feature, and you the satisfaction of no bad parts in the =20 kernel you object to. You don't go to court and tell someone is guilty and then the person =20 has to prove he/she is not guilty. To me your objection looks similar =20 to the way Microsoft talks about patent issues in Linux... "I know you =20 do bad things but I don't tell you what". We all know that a lot of =20 people don't like this way of "doing business". If someone thinks my =20 view of this is way off, please tell me. Really, I want to know about =20 this if you think this is the case. So please, tell with concrete examples what's bad and why in your =20 opinion, and let Constantine have a look at it. For newbus and =20 taskqueue(9) we already have pointers for improvement, and I assume =20 Constantine is looking at them now. As far as I know the personality =20 of Constantine (I don't know him personally, just what I've seen here =20 on FreeBSD lists and in some private mails from him), I think he =20 either will use all constructive criticism to improve the framework, =20 or come up with an explanation why it is not possible to integrate =20 this suggestion in the framework. Note: some people pointed out that Pouls initial behavior was =20 needlessly rude and notified core@ because of this. Regardless from =20 the fact if I agree or not, I want to tell you that I'm not pissed off =20 at all and haven't switched to some aggressive countermeasure mode. =20 While this may be more or less normal behavior for a human being in =20 such a situation, I have the opinion that such reactions just result =20 in a drop of life quality. I managed to teach myself to stay more and =20 more calm in such situations. Typically I switch to a reduced emotions =20 mode where I try to come up with logical arguments. So if someone =20 reads my mail in some aggressive way, please start again and imagine a =20 calm intonation with the intend of going forward in a way which is =20 beneficial for the FreeBSD project. I would also suggest that everyone =20 who wants to answer tries to step back for a moment to analyze his own =20 feelings. If those feelings are not calm, then I suggest to sleep a =20 night over an answer. 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 You know you've been spending too much time on the computer when your friend misdates a check, and you suggest adding a "++" to fix it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071015152408.10kvgtog6cooc4wc>