Re: [RFC] [PATCH 1/3] Allow to override the RTC alarm time

[David Brownell <david-b@pacbell.net>]

On Thursday 10 April 2008, Zhao Yakui wrote:
> At the same time there is another question about this.
> alm.enabled is related with AIE flag. When alarm is fired, the AIE flag
> won't be cleared automatically.

Are you sure?  I thought that bug was fixed... alarms
should be one-shot, not periodic.


> If we want to set alarm again, should we 
> turn off the alarm firstly?  

As a rule, yes.  We want to present a portable model for
RTC alarms, which fire exactly once.  The PC/AT model,
with wildcarding for hh:mm:ss (and maybe MM:DD, allowed by
ACPI extensions) is not very portable.

(By the way, if someone wants to take rtc-cmos off my
hands, I'd be glad to offload it ... my interest was
just to try to get the PC platform to play in the same
RTC space the other Linux platforms do!)


> > That's a fair question.  I don't think there's a good answer
> > to that with today's infrastructure.  Arguably, there should
> > be the notion of a number of clients, each of which get told
> > when the alarm they request fires.  But today, there's only
> > a single alarm, and a single client.
> 
> Agree. Now there is only one alarm and current infrastruture can't
> support more than two clients.

I don't see how it could be claimed to support two
clients.  The second one clobbers the first ...

Now, there *ARE* some RTCs that support multiple
alarms.  It's common in discrete I2C and SPI chips.
But that's a capability that's not currently exposed
by Linux; one of many, as noted in the current rtc(4)
man page (dated 2006-11-26 in my copy).

- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html