In message <[EMAIL PROTECTED]>, Alexander L
eidinger 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 :-)
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.
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
B) Why so much of it ends in the kernel
C) How it integrates into FreeBSD and for the places where
it does not (newbus ?) why it doesn't.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
