I have been playing with the rtc-CMOS device in a different scenario
the /usr/src/linux/Documentation rtc.txt example purposes. My goal is
evaluate how-to the device node should be managed if i need all the
rtc-stuff at the same application context.
An application could to process the three main RTC functionalities:
the update IRQ, the Alarm stuff and a faster clock so
How the application design should be broken?
Current device is single open designed, so the application MUST be
designed for one process, a main thread setup every component to move
the ISR through every functionality, easy! Now where the real action
;-), one possible scheme could be based on threads, so:
Q1. what happens if three customized threads are read blocked each one
using the device?
A1. My test says that the rtc-io interface for every "customized"
is complexed a lot. The read-information could be randomized over each
blocked read. I mean, the alarm thread decodes: ohhh this read data is
not for me it's only the update time interrupt, a similar case could
happen for the others. In such fashion, the thread which has a
read-block rate higher is the thread which should split the IRQ
information, cause very likely will suck the ISR at higher speed.
So, one needs to design the data exchange interface, a protocol to
potential dead-locking and so forth..
Q2. Uhmm Why the driver functionality has NOT been broken in three
Which is my real background? i am moving with a very similar RTC one
(mc48T59) in a embbeded environment, a linux-driver is planned. I saw
the rtc.o and the question arrives again:
Why re-create the wheel again?
My first feeling after reading the rtc chipset data sheet was Q2. I
already implemented multi-minor modules based on functionalities
in a single hardware device, and it has been (in general, up to now) a
good policy design ;-)
Opinions, suggestions, alternatives?
Thanks in advanced...