Date: Sun, 11 Nov 2007 08:26:51 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: rwatson@freebsd.org, cnst@freebsd.org, imp@freebsd.org, arch@freebsd.org Subject: Re: sensors framework continued (architecture) Message-ID: <3274.1194769611@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 11 Nov 2007 09:18:01 %2B0100." <20071111091801.761ba5c5@deskjail>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20071111091801.761ba5c5@deskjail>, Alexander Leidinger writes: >Quoting "Poul-Henning Kamp" <phk@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3274.1194769611>