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: <20061122213724.51c3e591@inspiron>
Date:	Wed, 22 Nov 2006 21:37:24 +0100
From:	Alessandro Zummo <alessandro.zummo@...ertech.it>
To:	David Brownell <david-b@...bell.net>
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 Mon, 20 Nov 2006 18:47:57 -0800
David Brownell <david-b@...bell.net> wrote:

> >  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.

 [..]

> >  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.

> 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.

 given the experimental status, I'm inclined to remove the /proc
 driver right now.

 Any objection?

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

-
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/