Re: Two issues with 2.4.18pre3 on PPC

[Tom Rini]

On Wed, Jan 16, 2002 at 12:25:25PM -0500, Eric S. Raymond wrote:
> Tom Rini <[e-mail]>:
> > Unless the user wants to use drivers/char/rtc.c because they're on a
> > chrp or prep box.
> 
> OK, so the derivation right side should change a little (I'll take a patch).

The problem is both drivers are viable options on PPC, and it's possible
to build a kernel (CONFIG_ALL_PPC) that works on both systems that can't
use d/c/rtc.c (pmac) and ones that can (chrp/prep).  And there are users
of d/c/rtc.c on that config even.
 
> The actual point is one of design philosophy.  Instead of presenting the 
> ser with unnecessarily platform-specific questions, we should be asking
> platform-independent (wherever this is possible) questions about the 
> *capabilities* he/she wants and mixing that wuith information about the
> platform.

I mostly agree.  But there's the design problem of 'CONFIG_RTC' meaning
PC-style RTC chip.  Just like 'CONFIG_SERIAL' currently means
ns1655x-style uarts.  Both of these should (and hopefully will) be fixed
in 2.5.x.  CONFIG_RTC should be mean, we have some sort of Real Time
Clock, now give it to me.  The code driver should be able to be told
what kind of clock we have (which, it currently can't, which is why
there's 3 'generic' rtc drivers but only 1 of which is in kernel.org
now).

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/