Re: sensors framework continued (architecture)

In message <20071111091801.761ba5c5@deskjail>, Alexander Leidinger writes:
Quoting "Poul-Henning Kamp" <phk@xxxxxxxxxxxxxx> (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@xxxxxxxxxxx | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"