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 07:13:07 +0000): > In message <20071015081507.yi9t4ot8asg0wcw4@webmail.leidinger.net>, > 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: > > I propose that we write our own C/C++ compiler in perl. > > You object to that. > > Then 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 to ask for reasons for the objection and the constructive continuation would be to point out weaknesses in an understandable way (and 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 kernel to userland in an unified way. No need to replicate a lot of code in a lot of places to export the data. When the data is out of the kernel in an unified way, one can do a lot of things with it in an automated way (e.g., use it in nagios or cacti, or whatever), but so far we don't have a framework for this. I don't say the sensors framework can not be improved (in fact we got some improvement suggestions) or that I know more than you, but I 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, please point out what you are talking about)... I assume you are still talking about the temperature sensors. I already told you last time that the current way (access to the i2c or smbus) needs more access rights than using the userland parts of the sensors framework. I can not remember that you objected to this security improvement or provided technical arguments which made this point obsolete. Feel free to point me to a corresponding mail I may have missed. Feel also free to point out where Constantine or me aborted discussing things with you, so far I remember that you didn't follow up on our last responses 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 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 and in the past. I haven't seen any word from you that those reasons 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) deal with newbus and provide an example. The suggestions also talk about using taskqueue(9) and some other things. This critique is what I call "constructive". From you I've only seen hand waving and whistle 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 scheduled to go into 7.0 (and based upon the constructive suggestions we got so far the code we have currently will not be in 7.0 for sure). The code we have currently doesn't harm the system, provides additional features, is far from seeing a release ATM (8.0 is about 18 months away, plenty of time to remove unwanted parts), and the primary author agreed to work on improvements. From an userlevel point of view the current offering is not bad. We get an unified way of getting status information in a safe way. From a developer which doesn't work on the framework point of view, the kernel compiles and is not destabilized by the commit. The framework is also not spread over the entire kernel. You object to the current implementation because you think it is bad. Ok, I don't object to your objection. All I ask is to put the cards on the table so that we can find a way forward. A way which gives the users the new feature, and you the satisfaction of no bad parts in the kernel you object to. You don't go to court and tell someone is guilty and then the person has to prove he/she is not guilty. To me your objection looks similar to the way Microsoft talks about patent issues in Linux... "I know you do bad things but I don't tell you what". We all know that a lot of people don't like this way of "doing business". If someone thinks my view of this is way off, please tell me. Really, I want to know about this if you think this is the case. So please, tell with concrete examples what's bad and why in your opinion, and let Constantine have a look at it. For newbus and taskqueue(9) we already have pointers for improvement, and I assume Constantine is looking at them now. As far as I know the personality of Constantine (I don't know him personally, just what I've seen here on FreeBSD lists and in some private mails from him), I think he either will use all constructive criticism to improve the framework, or come up with an explanation why it is not possible to integrate this suggestion in the framework. Note: some people pointed out that Pouls initial behavior was needlessly rude and notified core@ because of this. Regardless from the fact if I agree or not, I want to tell you that I'm not pissed off at all and haven't switched to some aggressive countermeasure mode. While this may be more or less normal behavior for a human being in such a situation, I have the opinion that such reactions just result in a drop of life quality. I managed to teach myself to stay more and more calm in such situations. Typically I switch to a reduced emotions mode where I try to come up with logical arguments. So if someone reads my mail in some aggressive way, please start again and imagine a calm intonation with the intend of going forward in a way which is beneficial for the FreeBSD project. I would also suggest that everyone who wants to answer tries to step back for a moment to analyze his own feelings. If those feelings are not calm, then I suggest to sleep a night over an answer. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 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>