Subject: Re: [linux-audio-dev] RTC Daemon Design
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ke loka 27 1999 - 15:34:46 EDT
In message <19991027163649.18977.qmail_AT_hyperreal.org>you write:
>[ I want to use /dev/rtc, but the idea that my app would block any
> other app from using it bugs me. Thus, this. -est :]
nice piece of work, except this:
>THE PROTOCOL
>
>Clients send the desired absolute wakeup time as a struct timespec.
>At or after that time, rtcd writes a uint8 to the client containing
>log2(<rate>). The client can thus wait by blocking on a
>read()/select() on the connection.
we want to be able to use the /dev/rtcd connection semantically just like
/dev/rtc, which means we should be able to get periodic "interrupts"
from the daemon. the way this is written makes it sound as if the
client *has* to always write back its "next wakeup time" every time it
is woken by the daemon.
thats ok for apps that want to use the rtcd as a non-periodic timing
source, but there needs to be support for a client to say "wake me
every N <unit of time>". this will help us minimize the client-daemon
traffic and work done by the client.
i would suggest that unit of time be milliseconds, specified as a
uint16. thus, the request "packet" is now:
#define RTCD_PERIODIC_REQUEST 1
#define RTCD_ONESHOT_REQUEST 2
struct rtcd_request {
unsigned char rtcd_type;
union {
struct timespec when;
uint16 interval_msecs;
} rtcd_r;
};
in addition, i'd suggest that a client cancels a periodic request
with:
req.rtcd_type = RTCD_PERIODIC_REQUEST;
req.rtcd_r.interval_msecs = 0;
this will be an exciting addition to our pantheon of "tools to make
cool applications". are you going to volunteer to write it as well ?
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST