On Mon, Sep 05, 2005 at 06:51:41PM -0700, David S. Miller wrote:
> Admittedly, the whole RTC situation is quite a mess I have to
> agree.
>
> To make the problem worse, we have two sets of RTC ioctls
> which userland makes use of on Sparc. The older ones which
> the SBUS RTC driver exported and supported, and the normal
> ones the rest of the world uses. Because the normal RTC driver
> gets used as well, userland actually tries both ioctl sets.
> Therefore, it probably would work to completely do away with
> the SBUS RTC ioctl support, and only use the normal ones.
>
> This would make using the generic RTC driver much easier, I
> would think.
Yeah... Note that what you've just called "generic RTC driver" is
*not* GEN_RTC; it's RTC.
>From my reading of that code, GEN_RTC should've been called FAKE_RTC...
AFAICS, more or less clean solution would be to split the damn thing
into frontend (parsing of ioctls, hopefully very few API variants) and
backend (set of methods for talking to real hardware, or, in this case,
fake of a hardware). With at most one backend selectable (i.e. select
in Kconfig) and frontend available if backend is selected. With any
luck we could eventually get frontends down to one; in any case, their
APIs have no place in include/asm-*
Note that e.g. fsckloads of MIPS RTC drivers would simply become backends
in that scheme; lots of duplicated glue would disappear from them...
I'll look into that once the things settle down a bit with handling the
-bird tree; if you get there first with the work you've mentioned above -
even better ;-)
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |