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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200611201847.58135.david-b@pacbell.net>
Date:	Mon, 20 Nov 2006 18:47:57 -0800
From:	David Brownell <david-b@...bell.net>
To:	Alessandro Zummo <alessandro.zummo@...ertech.it>
Cc:	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Russell King <rmk+lkml@....linux.org.uk>
Subject: Re: [Bulk] Re: [patch 2.6.19-rc6 1/6] rtc class /proc/driver/rtc update

On Monday 20 November 2006 3:13 pm, Alessandro Zummo wrote:
> On Mon, 20 Nov 2006 10:17:19 -0800
> David Brownell <david-b@...bell.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/