On Saturday 02 February 2008, Ingo Molnar wrote: > > * David Brownell <david-b@xxxxxxxxxxx> wrote: > > > On Saturday 02 February 2008, Ingo Molnar wrote: > > > > > > i'd really love to have a /dev/rtc device compatibility APIs, both > > > inside and outside the kernel. > > > > Unfortunately the /dev/rtc code became a legacy API for good reasons. > > > > Like not recognizing that all the world's not a PC, with a single RTC > > that clones a long-obsolete chip from Motorola ... and not having been > > specified in a hardware-neutral manner. Oh, and of course not all > > systems actually used the same RTC driver anyway; it's not like there > > was just *one* such programming interface to worry about. > > i dont get it - please give me specific technological reasons In a word: -ENOPATCH. ;) > why on my > PC /dev/rtc couldnt be mapped to /dev/rtc0 - without requiring any > user-space changes. The APIs seem mostly covered, or at least mappable. > Why should the transition to a new driver require user-level changes? > (beyond the obvious extensions, but those should show up as extensions.) So far as I'm aware, the only issue visible to userspace relate to the legacy driver's use of "/dev/rtc" not "/dev/rtc0" ... which has previously been "solved" by symlinking "rtc" -> "rtc0", possibly with assistance from udev. (Related: the major/minor number of /dev/rtc.) Is that your understanding too? The "why" is that nobody has been sufficiently bothered by the need to symlink that they produced a kernel patch to compensate. > In fact i detest the old RTC code with a vengence, so dont understand > this as some invitation to flame or something - i simply want YOUR new > code to be utilized more! Good to know! :) But so you're clear ... not "my" code, mostly. Alessandro Zummo started this framework, based in part on Russell King's framework for RTCs that were integrated into ARM based SOCs. I contributed a bunch, including rtc-cmos to let the PC side of Linux join the effort. > I just dont see the specific technological > reasons of why there is no .config switch to switch the legacy /dev/rtc > over to the new RTC driver and be done with it. Initially: because that idea hadn't been suggested. And because that sort of code migration on PC hardware needs to be done slowly enough that the migration issues have a real chance to surface. Issues like: - Change to the ACPI suspend/resume interactions broke RTC wakeup for a couple releases in the new RTC framework; now fixed. - HPET stuff. I think the recently merged HPET update may imply that rtc-cmos needs an HPET hook, but I've not looked at details. - Minor bugfixes, which have been resolved over time. - Your desire to keep using old /dev/rtc nodes (no symlink, so new kernels and old non-udev fileystems can mix). New issue, no patch. Nothing else come to mind. > I'd enable it in a > heartbeat and would encourage distros to do so. Are there missing APIs? > Is the ioctl API totally different? It's impossible to wrap it? See above. Once the HPET thing is resolved, I think distros can convert given some resolution of the /dev/rtc issue. > I'm not really interested in "this isnt a PC" arguments. Maybe because for you, it *is* a PC. ;) > The incompatibility is > such an obvious migration barrier to me - do you really not see it? Let's just say that all my PCs run the new code just fine, and not all of them have /dev/rtc symlinked to /dev/rtc0 ... but I can very easily imagine it look bit different from a distro perpective. - Dave _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
