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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20080614103800.GA5349@elte.hu>
Date:	Sat, 14 Jun 2008 12:38:00 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Brownell <david-b@...bell.net>
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

* David Brownell <david-b@...bell.net> wrote:

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

you are arguing against the facts - just look at the report - /dev/rtc 
broke and that shouldnt have happened and should be fixed. No amount of 
talking you do here will produce a working config.

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

i have hit 1400 kernel bugs in the past 6 months alone on my 
testsystems. That does not mean kernel bugs are the norm and it does not 
entitle me to ignore kernel bugs in the future?

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

uhm, there's no such thing as a "bogus configuration". The Kconfig rules 
for RTC (authored by you too) allowed it. If it "makes no sense" it's 
because you coded it so - deal with it, it's not hard. But instead of 
solving it (it is trivial) you are trying to push the blame to the user 
- and that is rather lame to do.

> Given a bogus configuration, how should it be fixed? [...]

this is not rocket science. The solution is to turn on the fine RTC 
code, if the old config option is enabled too. I.e. be more careful 
about compatibility. It's still possible to solve this problem and allow 
the RTC code to be compiled out completely.

and note that you are hurting users who tried out _your_ RTC code (which 
was default off in the past) previously. Yes, while experimenting with 
your code they might have created the "wrong" mix of config options but 
that's not a problem - this isnt some esoteric embedded platform where 
only real men are allowed to configure the kernel and who are left out 
in the cold if they mess up - this is Linux where we encourage (and beg) 
actual user to test our kernels. So please show some basic respect 
towards them and dont arbitrarily declare configs "broken" that were 
working in the past.

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