[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47ECE9BB.3050006@imap.cc>
Date: Fri, 28 Mar 2008 13:51:07 +0100
From: Tilman Schmidt <tilman@...p.cc>
To: David Brownell <david-b@...bell.net>
CC: Ingo Molnar <mingo@...e.hu>, Mark Lord <lkml@....ca>,
David Miller <davem@...emloft.net>, jkosina@...e.cz,
gregkh@...e.de, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org, pavel@...e.cz,
akpm@...ux-foundation.org, rtc-linux@...glegroups.com
Subject: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
On Fri, 28 Mar 2008 02:49:41 -0700, David Brownell wrote:
> It seems too many people are used to enabling a legacy RTC despite
> the Kconfig help/comments; the gentle approach hasn't worked.
Gentleness is not the point. The Kconfig help/comments where just
not clear at all.
FWIW, it's still confusing to have an option "Enhanced Real Time
Clock Support" under "Character Devices", then later an option
"Real Time Clock" one level higher, none of the two in any way
acknowledging the existence of the other one, and only after
naively selecting both, you are told that there is some sort of
conflict. Couldn't this be made more explicit, such as:
- mentioning in both options' help text that the other one
shouldn't be selected at the same time (if that's true)
- noting explicitly which of the two RTC options is the "legacy"
one (is it RTC_CLASS?)
- enhancing the conflict message, which reads, in git-current:
*** Conflicting RTC option has been selected, check GEN_RTC
*** RTC interfaces ***
Perhaps it's only me, but I do not know what to make of this.
HTH
T.
--
Tilman Schmidt E-Mail: tilman@...p.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Download attachment "signature.asc" of type "application/pgp-signature" (251 bytes)
Powered by blists - more mailing lists