linux-kernel - Re: [PATCH] fix RTC_CLASS regression with PARISC

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]

Date:	Mon, 08 Sep 2008 16:37:40 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	David Brownell <david-b@...bell.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Parisc List <linux-parisc@...r.kernel.org>
Subject: Re: [PATCH] fix RTC_CLASS regression with PARISC

On Mon, 2008-09-08 at 14:29 -0700, David Brownell wrote:
> > No, it's a regression.  ...  This turns off the ability to select
> > GEN_RTC if you've said yes to RTC_CLASS.  Since RTC_CLASS is currently
> > unsupported on parisc, we need to fix that by making the RTC_CLASS
> > option unselectable on parisc.
> 
> So you affirmed that there was no override, AND that it was
> previously treated as junk DNA (ignored).  So just what were
> you disagreeing with me about??

The fact that the override you put in to disable GEN_RTC is causing a
regression.

> I have a hard time calling something a regression which
> was never really a supported configuration.  And which
> still *JUST WORKS* in those defconfigs ... given all that,
> it's hard to argue that something is actually broken.

On 2.6.25 the parisc users got a working realtime clock.  On 2.6.26 they
can find themselves without one using the same .config file.  This is
the regression.  The fix is to disable RTC_CLASS until we have it
working for parisc.

> Kconfig is not about letting Aunt Tillie configure kernels
> without being able to shoot herself in the foot.  That
> discussion has been had (at length!) before.  Result, we
> have a much better kernel config framework ... but still
> don't facilitate "Kconfig-4-dummiez" audiences.

Kconfig is complex enough that we try not to trip users up by hiding
things, especially when it's the wrong thing to hide on this platform.
If an option specifically doesn't work or causes harm on a platform, it
shouldn't be selectable on that platform.  This isn't Aunt Tillieism,
this is called common sense.

James


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