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 ...

[Poul-Henning Kamp]

In message <20071014172115.GA24318 at freebie.xs4all.nl>, Wilko Bulte writes:

>Poul, any chance you can make your comments sound a bit less like a
>personal attack and a bit more focused on the technical side of things?

There is nothing personal in my complaint, and to underscore that,
I will state for the record here that I have no complaint against
with any of the persons involved.

My only beef is with the architecture of the sensors framework, and
as a consequence thereof, with the actual code as well.

I think porting the sensors framework from OpenBSD to FreeBSD was
a very worthwhile SoC task, since it allows people to see, running
under FreeBSD what a mess it is architecturally.

And as far as I know the porting has been carried out competently and
well, fully living up to the SoC charter and rules.  I have absolutely
no problem with that part of the equation.

But being successfull in a SoC sense of the task does not, and
should not, imply that we will uncritically import the resulting
code in FreeBSD without architectural review.

In OpenBSD the sensors framework has already turned into a dumping
ground, and I have all reason to belive that we will see the same
under FreeBSD.

See for instance Marc Balmers presentation from EuroBSDcon2007 about
putting radio-timecode receivers under the sensors framework, or
listen to the various mumblings about putting RAID-controller status
under sensors framework.

IFF we want to have a general catch-all framework for representing
any oddball state, LED or measurement in the computer, then we want
it to be much better structured than the code we are discussing now.

But it is not even clear to me that we want such a framework, it makes
much more sense to keep the various indicators, measurements and
other input in their respective subsystems.

And IFF we add such an amount of code to FreeBSD, we want to have it
properly integrate into our kernel, using our device discovery
and registration (newbus) and not probing random (i2c) busses willy
nilly.

-- 
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.