sensors framework continued (architecture)

[Poul-Henning Kamp]

In message <20071113215117.3b9bab8c at deskjail>, Alexander Leidinger writes:

Alexander,

This discussion is leading nowhere, because no matter what we tell
you, your only focus is to prove that "sysctl can do that also".

There are so many interesting things we could work together on in
this area, and I have quite a bit of interesting code I could
contribute (see http://phk.freebsd.dk/phkrel/Measure.20071017.tgz),
but we never get to that point because of your rather childish
insistence that sysctl is the only and right way to do this.

It also gets more than a bit tedious after a while, and I have
decided that I do not want to continue wasting my time discussing
this, until you are willing to compromise on your sysctl addiction.

So let me make my position 100% clear:

1.  I would LOVE to see FreeBSD grow competent support for managing
    sensors, (and possibly actuators).

2.  I have many years of experience and a fair bit of code I can
    and will contribute to such a project.

3.  I don't want some half-assed, badly thought out "it works
    for me" crap, because I have spent most of my FreeBSD years
    cleaning that sort of stuff up, and I'm trying to break the
    habbit.

4.  Therefore, any attempt to get sensorcode into FreeBSD that does
    not comply with the architectural model set out below will be
    met with my full effort of resistance.

5.  The ball is now in your court.

Sincerely,

Poul-Henning


High-level architectural view of sensor support
-----------------------------------------------

    N * application (linked -lsensor)
	    |
	    |
	1 * sensord ---- N * userland-sensors (linked -lsensor)
	    |	
	    |
	1 * sensor multiplex device driver
	    |
	    |
	 N * kernel sensors

(There may also be a connection from the multiplex driver to devd(8)
or it may be from sensord(8) or possibly both, but that could come
later.)

The sensor daemon is there to act as clearing-house and single
configuration point for the sensors, because I really don't want
to have all the sensors polled by all the applications and I don't
want all the applications to have to read the config file and do
calibration/alarm calculations themselves.

In my experience, it makes sense to not restrict the userland side
communication to UNIX sockets, since being able to access another
machines sensors using TCP saves a userland process on that machine.


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