sensors framework continued (architecture)

[Poul-Henning Kamp]

In message <20071111091801.761ba5c5 at deskjail>, Alexander Leidinger writes:
>Quoting "Poul-Henning Kamp" <phk at phk.freebsd.dk> (Sat, 10 Nov 2007 22:54:41 +0000):
>

>> But you forget that sensors may have considerable "conversion" time.
>> It is a benefit for us to be able to start the sensor and not block
>> on the syscall waiting for it to do its thing.
>
>How do you know from the approach you propose when to read out the
>newly polled data without blocking in some syscall? 

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.

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

>How do you
>quantify "a problem"? Can this problem be circumvented by userland code
>instead (maybe some tunable amount of threads or some other way)?

Anybody who proposed "a tunable amount of threads" a solution where
poll(2)/select(2)/kqueue(2) would do just fine, doesn't know what
he is talking about.

>I don't say your proposal is bad, currently I still think you are in
>the premature optimization territory [...]

No, this is purely architectural, it has nothing to do with "premature
optimization".

>> You are reading waaay too much into Roberts email and overlooking
>> that a fd based kernel interface can also be MIB based.
>
>I don't overlook the MIB based part. I see that we get the MIB part via
>sysctls for free, and that we have to write a filesystem with all the
>bells and whistles VFS needs to work, to get this MIB based part via
>the fd approach.

Ahh, here we have the misunderstanding!

Nobody is proposing writing a filesystem, which would be a terribly
stupid way to do it.

To see why a filesystem isn't needed, please study devd(8)'s
kernel interface.

We can continue when you have done so.

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