lkml.org 
[lkml]   [2011]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [rtc-linux] [PATCH 04/10] RTC: Cleanup rtc_class_ops->read_alarm()
On Tue, 22 Feb 2011, john stultz wrote:
> On Tue, 2011-02-22 at 21:05 +0000, Mark Brown wrote:
> > On Tue, Feb 22, 2011 at 12:22:54PM -0800, john stultz wrote:
> >
> > > In some ways it does complicate things, but in others it greatly
> > > simplifies it. You don't have to have 80 drivers each implementing their
> > > own code to set a mode that isn't used. Everyone is using the common
> > > kernel code, so bugs are shared and thus found and fixed faster.
> > > Features can be more easily added, as the limitations of specific
> > > hardware have to be more formally expressed, rather then having to
> > > change 80 drivers that opaquely work around their specific hardware
> > > issues. Also, applications are easier to port, since there are less
> > > platform specific differences.
> >
> > I agree that it's a win for things like UIE - the reason it worries me
> > for alarms (and the RTC time itself) is that full emulation requires us
> > to do things over reboots, including the support for having multiple
> > alarms scheduled which isn't available on most hardware at all.
>
> Hmm. Maybe I'm missing what you mean again. If the RTC doesn't support
> alarms, we don't emulate them (or RTC time).
>
> But if you just mean trying to keep multiple alarms scheduled across
> resets, I don't think that is something we can emulate (since the kernel
> doesn't have any other persistent storage). But due to the lack of
> consistency in RTC hardware, I don't think its a reasonable expectation
> for applications to have.
>
> We can preserve what hardware state we can at boot, but applications
> should not expect alarms set multiple reboot cycles ago to be valid.
> After all, other applications might have jumped in and grabbed the rtc
> device and set it to something else before the application was able to.
> Or a user might change the value from something like a bios menu.

Ack. Anyhting which relies on such a feature is broken by
definition. A sane requirement is that the last set earliest alarm
survives, but anything else is just beyond the scope of a sane
interface.

Thanks,

tglx


\
 
 \ /
  Last update: 2011-02-22 22:31    [W:0.075 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site