From: Thomas Gleixner <tglx@linutronix.de>
To: john stultz <johnstul@us.ibm.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
rtc-linux@googlegroups.com, LKML <linux-kernel@vger.kernel.org>,
Alessandro Zummo <a.zummo@towertech.it>,
Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
Subject: Re: [rtc-linux] [PATCH 04/10] RTC: Cleanup rtc_class_ops->read_alarm()
Date: Tue, 22 Feb 2011 22:27:12 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.00.1102222225060.2701@localhost6.localdomain6> (raw)
In-Reply-To: <1298409673.9215.84.camel@work-vm>
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
next prev parent reply other threads:[~2011-02-22 21:29 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-21 23:55 [PATCH 00/10] [RFC] RTC: Cleanups for 2.6.39 John Stultz
2011-02-21 23:55 ` [PATCH 01/10] RTC: Cleanup rtc_class_ops->irq_set_state John Stultz
2011-02-21 23:55 ` [PATCH 02/10] RTC: Cleanup rtc_class_ops->irq_set_freq() John Stultz
2011-02-21 23:55 ` [PATCH 03/10] RTC: Cleanup rtc_class_ops->update_irq_enable() John Stultz
2011-02-21 23:55 ` [PATCH 04/10] RTC: Cleanup rtc_class_ops->read_alarm() John Stultz
2011-02-22 2:34 ` [rtc-linux] " Mark Brown
2011-02-22 2:55 ` John Stultz
2011-02-22 8:09 ` john stultz
2011-02-22 12:51 ` Marcelo Roberto Jimenez
2011-02-22 19:35 ` john stultz
2011-02-22 19:51 ` Mark Brown
2011-02-22 19:58 ` john stultz
2011-02-22 21:26 ` Marcelo Roberto Jimenez
2011-02-22 18:16 ` Mark Brown
2011-02-22 19:51 ` john stultz
2011-02-22 20:00 ` Mark Brown
2011-02-22 20:22 ` john stultz
2011-02-22 21:05 ` Mark Brown
2011-02-22 21:21 ` john stultz
2011-02-22 21:27 ` Thomas Gleixner [this message]
2011-02-22 21:40 ` Mark Brown
2011-02-22 21:33 ` Mark Brown
2011-02-22 22:10 ` john stultz
2011-02-22 23:07 ` Mark Brown
2011-02-22 19:53 ` john stultz
2011-02-22 20:31 ` Mark Brown
2011-02-21 23:55 ` [PATCH 05/10] RTC: Clean out UIE icotl implementations John Stultz
2011-02-21 23:55 ` [PATCH 06/10] RTC: Include information about UIE and PIE in RTC driver proc John Stultz
2011-02-21 23:55 ` [PATCH 07/10] RTC: Remove UIE and PIE information from the sa1100 " John Stultz
2011-02-21 23:55 ` [PATCH 08/10] RTC: Fix the cross interrupt issue on rtc-test John Stultz
2011-02-21 23:55 ` [PATCH 09/10] RTC: sa1100: Update the sa1100 RTC driver John Stultz
2011-02-21 23:55 ` [PATCH 10/10] RTC: Fix up rtc.txt documentation to reflect changes to generic rtc layer John Stultz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.1102222225060.2701@localhost6.localdomain6 \
--to=tglx@linutronix.de \
--cc=a.zummo@towertech.it \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mroberto@cpti.cetuc.puc-rio.br \
--cc=rtc-linux@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®