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]
Message-Id: <200806131538.54254.david-b@pacbell.net>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ