Messages in this thread | | | Date | Fri, 17 Sep 2010 09:52:07 +0200 | From | Richard Cochran <> | Subject | Re: [PATCH] Posix CLOCK_RTC interface proof of concept |
| |
On Thu, Sep 16, 2010 at 12:41:32PM -0700, John Stultz wrote: > Exposing multiple RTCs via the posix clock interface has some tradeoffs. > > a) Some application programmers may really want to see the underlying > hardware and be sophisticated enough to deal with the multiple, > possibly unsynchronized, time domains. > > b) Some application programmers may not care about the hardware, and > just want a interface that works like CLOCK_REALTIME, but fires > wakeup alarms if the system is suspended.
I like the idea of offering the high-level posix clock API for various hardware clocks. Also, keeping low-level access for specialists makes sense, as long as there is a way to enforce correct access control. If we make the posix clocks truly dynamic (with removal, too), then one could offer a low level funtion to grab the clock before use.
> Exposing all the RTC devices in a somewhat raw manner is probably > the most straight forward. Some extra infrastructure, like > the dynamic posix-clockid allocation Richard Cochran has > started to look into will be needed. More concerning is that > this will probably cause some grief if someone creates a cron-like > tool that uses the RTC where the RTC isn't exactly synced with > system time. When the user specified a job for 6am, do they mean > 6am system time, or RTC? > > And note: on many PCs, the RTC is synchronized, but kept in local > time, not UTC. So the unsynched RTC case is likely to be common.
We could also advertise the clocks properties (eg timescale) via sysfs (or clockfs, as Greg K.H. put it).
> 3) Adding the posix time interface makes it easier to have finer > grained capability management to decide what applications can > set a alarm timer. While this is great for creating applications > that can wake servers up from suspend mode, and simplifying the > wakeup infrastructure on cell phones, some systems may not > want applications being able to set wakeup timers. I can > imagine the "laptop in well insulated carry-on luggage" case > that comes up occasional being one of them. So some additional > thought and policy may be needed to decide when non-user-triggered > wake events should be masked or not in suspend.
Again, implementing dynamic clocks would allow the sysdadmin to just remove the clock whenever it might cause trouble.
Overall:
I only took a quick look at the patch, but I like the general idea.
You introduce posix timers that are *not* based on the hrtimer code, but rather on a second implementation. I wonder whether one could abstract the timer management code to work with different clocks.
I have been thinking about that for the PTP hardware clock stuff and will soon post a new round of patches.
Thanks, Richard
| |