Re: 2.6.21-rc2 : Oops in rtc_cmos...

[David Brownell <david-b@pacbell.net>]

On Tuesday 06 March 2007 8:42 pm, Paul Rolland wrote:

> It seems to me that the DRV_RTC_CMOS and the "standard" CONFIG_RTC
> shouldn't be used at the same time... Am I correct on that ? 

Yes.  I recall not forcing that because I couldn't be sure the new code
was functionally identical to the legacy driver ... and in areas like
HPET, knew it was not.  Of course, since then I see that someone has
kicked in a patch making Linux stop using HPET in legacy-replacement
mode, so that particular issue now seems moot.

Another area it's not functionally identical is CONFIG_SND_RTCTIMER,
where the ALSA code doesn't know how to use the new RTC framework.
(Or, probably, cope with the fact that not all RTCs can give periodic
IRQs at the rates it wants ...)

So it wasn't clear to me that distros might not need to have both
options, to help cope with strange hardware.  Phasing out legacy code
tends to be done a bit cautiously.

On the other hand, the distro vendors have been slow to look at this
issue, and haven't even upgraded their copies of "hwclock" to be
able to recognize /dev/rtc0, so I'm not holding my breath there.


> Wouldn't it be better to have this dependancy enforced ?

Feel free to submit a patch updating the Kconfig for both drivers.

Merging it might complicate distro efforts to move away from that
legacy driver (by preventing systems that can run with either one),
but I don't see that happening very quickly anyway.

- Dave