David Brownell wrote:
quoted text
> On Friday 30 November 2007, Pavel Machek wrote:
>>> It's not an issue of accidental writes, it's an issue of there being
>>> no other synchronization for setting those alarms.  Remember that both
>>> RTC_WKALM_SET and RTC_ALM_SET ioctls can set that same alarm, and so
>>> could a different userspace activity ...
>> We have 3 interfaces to one hardware resource. I do not think kernel
>> should try to arbitrate it here. There's just one alarm clock with
>> three interfaces.
> 
> Having three interfaces is bad enough ... ensuring that none of
> them can ever be used safely would be stupid.
> 
> 
>>> As written, this allows one userspace activity to clobber another if
>>> it does so explicitly, by first disabling the other one and then
>>> setting its own alarm.  But the idea is to minimize "accidents" like
>>> unintentionally clobbering an alarm set by someone else.
>> Well, I could not get it to work with this "avoid-clobber" feature.
> 
> I had earlier pointed out a different issue, whereby "oneshot"
> semantics weren't consistently followed.  I've been working on
> some patches to address that.  The ACPI bits still need work,
> but I'll forward one part soonish.
> 
> 
>>>> If I remove "accidental alarm modify" logic, I can actually use rtc to
>>>> wake up more than once per boot.
>>> Evidently the alarm isn't being disabled then...
> 
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That's the issue addressed by those patches.  (Specific to rtc-cmos,
> not to RTCs on saner hardware.)
> 
> 
>> I think we should just remove the 'avoid-clobber' logic. If userland
>> wants to somehow arbitrate access, it can.
> 
> Pray tell, *HOW* could it arbitrate?
...

This is really a non-issue in practice.  The thing requires root access,
and there's only a single user at most for it on a given system.

This is used by media boxes to power off (or suspend) between recording times.
And similar stuff.

It might be nice to fix it all, but the current state really isn't hurting anything.

Cheers
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/