Date: Sat, 10 Nov 2007 22:54:41 +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: <1402.1194735281@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 10 Nov 2007 20:32:29 %2B0100." <20071110203229.64021d85@deskjail>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20071110203229.64021d85@deskjail>, Alexander Leidinger writes:
>Quoting "Poul-Henning Kamp" <phk@phk.freebsd.dk> (Sat, 10 Nov 2007 10:04:22 +0000):
>
>> >This
>> > implies that we have to move the polling intervall code for non-event driv
>> >en sensors from the userland to the kernel.
>>
>> No it does not.
>>
>> It would be prefectly sensible to have an ioctl(2) (or write(2)!)
>> that says "poll this sensor now" to keep control in userland if
>> that is desired.
>>
>> Some sensors however, are hardware timed, and for those it makes
>> more sense to be able to tell them "we want one report every second"
>> and not worry more about it.
>
>Two kinds of behavior come into my mind when I read this.
>
>First behavior ("poll this sensor now"): If the userland application
>wants to poll the non-event driven sensors (or sensors which are not
>hardware timed), it has to issue 2 syscalls for each sensor, one to let
>it poll (ioctl), and one to read the data. The polling interval is
>handled by the userland.
>
>What I like here is, that the polling interval handling is in the
>userland for non-event driven and non-hardware-timed sensors (let's
>call those "simple" sensors). What I don't like is that we have to issue
>more than one syscall.
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.
>> >So to sum it up it looks like the architecture looks as follows:
>> > - using sysctls for centralized exporting of sensor data from kernel
>> > to userland (polling interface for userland polling code)
>>
>> I think you are jumping to conclusions here.
>
>As written, nobody came up with strong arguments (actually there where
>no replies at all) to Roberts mail.
You are reading waaay too much into Roberts email and overlooking
that a fd based kernel interface can also be MIB based.
>> sysctl is by definition limited to polling, which, for any significant
>> number of sensors, becomes very expensive compared the ability of
>> an fd-based approach to queue and batch data.
>
>See my caching argument above.
Which just adds to the mess, because then you have to also pass
along a timestamp to tell how old the returned value is.
There are a lot of downsides to sysctls which you do not seem
to be aware of, locking, access time, overhead and several other
issues makes sysctl very undesirable for anything which isn't
"ad-hoc" or really seldomly used.
Poul-Henning
--
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?1402.1194735281>