sensors framework continued (architecture)

[Poul-Henning Kamp]

In message <20071111113717.4803b3ab at deskjail>, Alexander Leidinger writes:

>> You use the select(2), poll(2) or kqueue(2) systemcall to wait until
>> one of the several fd's the sensord(8) process will have to service
>> becomes ready.
>
>This sounds like you propose more than one kernel access point for all
>sensors. Maybe something like /dev/sensors/senX instead of
>the /dev/sensor_interface I thought initially?

One device node is plenty:  /dev/sensors

>the /dev/sensor_interface I thought initially? What about the
>hierarchic aspect (/dev/sensors/hierlev1/.../hierlevX/senY, ... this is
>where I came up with my filesystem comment in the previous mail)?

There is no need to waste device nodes and vnodes on that, it can
be more efficiently encoded inband, just like devd does.

>(the simple sensors)), or you issue an "poll now" ioctl each time you
>want the data and wait for the return of the select/poll/kqueue. So in
>the end you do a blocking wait, with slow sensors comming back later
>than faster ones, and in the monitoring software those get attributed
>to about the same time slot (if they are all polled at the same time).

That would only happen if you implement things in a truly pointless
way.

>As I don't like the generic poll logic for simple sensors (used in the
>majority of use cases) in the kernel, let's look at the "poll
>now"-case: 1 syscall for the "poll now" for each sensor (N calls),

Why couldn't you tell multiple sensors to poll in one syscall ?

>1-N
>syscalls for waiting, and 1 syscall to read for each sensor (for only
>one fd for all sensors, 

And read all the results in one read(2) operation, if they are ready ?

You sound like an IBM mainframe-guy: "There shall be one record per
syscall only!" :-)

You could, best case, poll _all_ the sensors in two syscalls.

>The simple sysctl approach has N calls.

Which is a terrible waste of syscalls in my mind.

>Again: when does it hurt that it takes longer?
>
>For sysctls you go directly to a sensor (benefit of the hierarchic
>property), for the single fd approach you need additional code in the
>kernel to go dispatch to the sensor,

You mean, code that isn't hampered by the sysctl semantics and which
can do so in a very efficient way ?  Yes, that would be a great
thing indeed.


>and in the multiple fd case you
>need to write some kind of filesystem logic to get the hierarchical
>benefit.

Only you talk about one devicenode per sensor, please forget that
red herring.

>> Remember the userland access API ?  That will need to be serviced
>> via some kind of interface, most likely a unix domain socket (although
>> a shared memory based interface might also work).
>
>Why? We want a userland library to access it, so all tools which query
>a sensor need to use this. This library can access the interface
>directly [...]

No, then you clearly have not understood what people told you, the
diagram looks like this:


	N * accessing application
		|
		|
	   N * sensor-library
		|
		|
	    1 * sensor daemon ---- N * sensor-library - N * userland sensors
		|	
		|
	     N * kernel sensors


>You propose to write more code with more complex logic to get faster
>to the sensor data.

No, I propose to solve the problem, rather than hack up bad code
using bad interfaces for 20% of the problem.


>I've done this. Passing strings down a fd from the kernel is no magic.
>It's good for the kernel->userland part, but not for the
>userland->kernel querying of only a subset of the sensors. 

Here is a straw-man API for the kernel<->userland device:

	Kernel sends
		"S 32 acpi.cpu.0.temperature bla bla bla\n"

This means:  I have a sensor which I know as number 32, and it tells me
it has these properties.

	Userland does an ioctl:

		SENSOR_POLL(32)

	Kernel sends, when the data is ready,
		"D 32 34.45\n"

There you are, can it be any simpler ?

Amongst the points you totally overlook, is the fact that the sensors
don't need to be a hierarchy in the kernel, as long as they tell
sensord about their placement in the hierarchy.

In fact, if for no other reason, the tremendous overhead for the
hierarchy in sysctl is reason not to use it.
to sysctl for this.

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