Quoting Poul-Henning Kamp <[EMAIL PROTECTED]> (from Mon, 15 Oct 2007
07:13:07 +0000):
In message <[EMAIL PROTECTED]>,
Alexander Leidinger writes:
Quoting Poul-Henning Kamp <[EMAIL PROTECTED]> (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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
