Re: [linux-audio-dev] RTC Daemon Design

New Message Reply About this list Date view Thread view Subject view Author view Other groups

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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST