[linux-audio-dev] RTC Daemon Design

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

Subject: [linux-audio-dev] RTC Daemon Design
From: est_AT_hyperreal.org
Date: ke loka   27 1999 - 12:36:49 EDT


[ 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 :]

RTC Daemon Design

MOTIVATION

* Stock linuxes aren't going to set the timer interrupt to above 100
  HZ anytime soon.

* Still, we'd like to be able to sleep for sub-tick intervals with
  reasonable accuracy.

* /dev/rtc is available and can produce interrupts at up to 8192 HZ.

* However, /dev/rtc can be used by only one process at a time.

* This makes /dev/rtc a good candidate for use by a daemon which can
  serve its functionality to multiple processes

* Processes needing this functionality can attempt to connect to the
  rtc daemon and, only if that fails, attempt to seize control of
  /dev/rtc itself.

DESIGN

rtcd [ <rate> [ <unix domain socket> ] ]

rtcd must be started by root. It sets its scheduler to SCHED_RR with
high static priority (90? command line option?). It binds <unix
domain socket> (default /dev/rtcd). It opens /dev/rtc and sets
periodic interrupts to <rate> (which must be a power of 2 between 2
and 8192; default 2048). Unix domain connections are accepted on
<unix domain socket> and rtcd speaks rtcd protocol to these
connections.

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.

OTHER DETAILS

rtcd's Main Loop:

 wait on /dev/rtc
  get the current time
  run through the connections and do any processing needed
  select() on connections
  read requests
    and note them as time/connection pairs on time-sorted priority q
  pop elements off front of priority q with time >= now
    and send wakeups to their connections

rtcd needs to operate on client connections in non-blocking mode. If
writing on a connection would block (which would probably indicate a
serious design problem in the client), it should be shut down..at
least after a few tries..and a syslog entry written.

rtcd shuts down on SIGHUP.


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