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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
