sensors framework continued (architecture)

[Alexander Leidinger]

Quoting "Poul-Henning Kamp" <phk at phk.freebsd.dk> (Fri, 16 Nov 2007 10:29:25 +0000):

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

Sorry, you misinterpreted what I say, see below.

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

I don't insist that sysctl is the only right way to do this. I think
that your proposal is more complex without providing a real benefit for
us. Go back and read the mails again. I explain why I think that
several pieces of code you propose (for functionality in the kernel)
belong into the userland. And I explain how this can be done with less
complex code. And I ask questions to give you the possibility to show
me that I'm wrong. You didn't answered most of the questions, and the
few questions which you answered, where not one of those where you had
the change to show that your approach is superior. So far your mails
can be interpreted as one of the following possibilities in my eyes:
 - premature optimization
and/or
 - second system syndrome
and/or
 - resistance about giving an architecture a change which you
   rejected before without looking what the architecture is
   you reject (I'm talking about Constantines work in this item)
and/or
 - trying to fit 1% more use-cases into the kernel with a lot more
   complexity/code into something which can be handled in userland

It may also be the case that you are right and I am wrong. Show me the
facts I asked you about here on arch@ to show that I overlooked
something important which makes your more complex proposal the better
one, and I'm quiet.

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

A compromise is something which, e.g., takes parts of the proposals of
2 opposing parties to get a solution in the middle. What you propose is
not a compromise, it's either your solution or nothing. Sorry Poul, it
doesn't work like this. Go back, read my questions, and provide hard
facts / good arguments I can not disprove to show that your solution is
better than the one I propose (and showed it is able to handle the
features you want). Do it and you get my support. Don't do it and I ask
around for an explanation why your proposal is better. If I don't get
such an explanation, I will ask around if the people see a problem with
my proposal. If they don't see a problem, your proposal lost, as it is
more complex (code in the kernel for things which can be done in
userland). Note: I'm talking only about the kernel interface, not about
the userland parts.

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

So you deny the people which participated in the beginning to voice
their opinion about this and want to force this architecture upon them
(your mails sounds like this)? While I have no strong opinions about
the pure-userland part of the architecture ATM, I think it deserves
some more discussion on arch@ instead of forcing this architecture
based only upon your opinion / view of the world. A good team is able
to deliver a better architecture than one person.

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

What about a hybrid approach, using sensord when it is available, and
reading the sensor data directly if it is not activated? This way you
can even get to the sensor data when you are in single-user mode and
don't need a fully functional system. In case you have a problem which
only gives you single-user mode with limited resources, but can be
solved fast when you have the sensor data, your approach is not really
a good solution. Whatever solution is taken for the pure-userland part,
I think it needs to work without a daemon running to be useful even in
troubling situations. I don't object to have a daemon running and all
userland applications connecting to it when the system is ok, I only
object if I can not get to the sensors data of the machine if the
system is mostly down. Sensor data can be very valuable in such a
situation.

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

Typically a lot of daemons provide both options. This way you don't
have a TCP socket visible to the network if you don't need it (the
"bind to localhost" argument only counts when you teach jail to provide
a localhost on it's own instead of only one official IP). Do you want
that there's only a TCP socket, or is it ok for you to have both kind
of sockets?

Bye,
Alexander.

-- 
A snake lurks in the grass.
		-- Publius Vergilius Maro (Virgil)
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137