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 ...
phk at phk.freebsd.dk
Mon Oct 15 00:13:10 PDT 2007
In message <20071015081507.yi9t4ot8asg0wcw4 at webmail.leidinger.net>, Alexander L
>Quoting Poul-Henning Kamp <phk at phk.freebsd.dk> (from Sun, 14 Oct 2007
>> 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
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 Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the cvs-src