lkml.org 
[lkml]   [2008]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-pm] sleepy linux self-test

* David Brownell <david-b@pacbell.net> 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 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.)

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! 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. 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? I'm not
really interested in "this isnt a PC" arguments. The incompatibility is
such an obvious migration barrier to me - do you really not see it?

Ingo


\
 
 \ /
  Last update: 2008-02-02 19:09    [W:1.096 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site