linux-kernel - Re: [Bug 10866] /dev/rtc was missing until I disabled CONFIG_RTC

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 13 Jun 2008 15:38:54 -0700
From:	David Brownell <david-b@...bell.net>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Lior Dotan <liodot@...il.com>, Adrian Bunk <bunk@...nel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, a.zummo@...ertech.it,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	bugme-daemon@...zilla.kernel.org, rtc-linux@...glegroups.com
Subject: Re: [Bug 10866] /dev/rtc was missing until I disabled CONFIG_RTC_CLASS

On Friday 13 June 2008, Ingo Molnar wrote:
> 
> 	 Smooth migration via "make oldconfig" 
> is a must, otherwise we'd lose testers and users.

Yes, but "smooth" doesn't mean there's never a need to cope
with kernel updates by running "xconfig" (or whatever).

In my own experience, several times a year I need to go back
and patch up a mess that "oldconfig" made.  Things drop out,
things get added ... it's the things that get *added* without
even a by-your-leave which often seem hardest to fix.

> 	 you might as well think about the other 98% of 
> users who used the old /dev/rtc with old kernels. (not because they 
> wanted to use bad code, but because simply that was the default)

They can continue working just fine with *only* the legacy RTC.
If they stuck with defaults, no problems appear.  (Modulo the
fact that bitrot is setting in.)

The only thing that causes the least hiccup is someone who was
for a while using a bogus (and non-default) configuration.

Given a bogus configuration, how should it be fixed?  There
can be several solutions, and the right answer for one system
will always be the right one for another.  So any approach
that doesn't expect a human to select options sometimes will
be inherently wrong in various cases.

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