Re: [Bulk] Re: [patch 2.6.19-rc6 1/6] rtc class /proc/driver/rtc update

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

On Monday 20 November 2006 3:13 pm, Alessandro Zummo wrote:
> On Mon, 20 Nov 2006 10:17:19 -0800
> David Brownell <david-b@pacbell.net> wrote:
> 
> > Fix two minor botches in the procfs dumping of RTC alarm status:
> > 
> >  - Stop confusing "alarm enabled" with "wakeup enabled".
> > 
> >  - Don't display bogus "irq pending/un-acked" status; those are the rather
> >    pointless semantics EFI assigned to this (for a no-IRQs environment).
> 
>  I wouldn't change that, the /proc interface to rtc is old
>  and should not be used anyhow. Here I'm trying to mimic
>  the behaviour of the original one.

The "original" one never had such fields.  Even the efirtc.c
code (which originated those flags) didn't call them that;
it used "Enabled" not "alrm_enabled", so at least this patch
moves closer to that "original" behavior.


>  sysfs provides a much better interface
>  (once we'll have all the attributes exported, of course :) )

That's an orthgonal issue.  (Though one can argue that the
procfs file should be /proc/driver/rtc0 etc, one per RTC,
rather than /proc/driver/rtc...)


>  I don't know if there's any user space tool relying on this.

There shouldn't be any code parsing /proc/driver/rtc ... if there
is such stuff, it's already got so many variants to cope with that
adding one that actually matches the rest of the system would be
a net simplification.


>  If yes, then it should be fixed.
> 
>  Any thoughts?

The whole RTC framework is still labeled "experimental", and
AFAIK I'm the first person to audit the use of those flags.

Until it's no longer experimental, I have a hard time thinking
that backwards compatibility should prevent fixing such interface
bugs ... interface bugs are normally in the "fix ASAP" category,
since if you delay fixing them the costs grow exponentially.

- Dave