Re: [PATCH] fix RTC_CLASS regression with PARISC

[David Brownell <david-b@pacbell.net>]

On Monday 08 September 2008, James Bottomley wrote:
> 
> > > OK, I can look at that, but in the mean time could we make the option
> > > that causes the damage unselectable?
> > 
> > I'd worry if "the mean time" takes too long.  But lacking a
> > PARISC laptop to fix this on, I'm unlikely to complain much.
> 
> What is the expectation?  If you're expecting all the architectures to
> migrate over to RTC_CLASS, actually telling linux-arch and saying why
> its a good idea would have been helpful.

Folk have been migrating already.  IMO there's no rush ... but
similarly, retrograde motion should be discouraged.  (Same issue
with essentially all legacy code in the tree.)


> All the PDC real time clock calls can do are read and set, nothing else,
> so it's idealy suited to the GEN_RTC infrastructure ... what's the
> benefit in moving it to RTC_CLASS?

The same benefit always found in sharing infrastructure.  Lots
of little differences/bugs go away.  Infrastructure improvements
and bugfixes get leveraged.  Dead and crufticious code can vanish.
And so forth.


> > >      This is technically a regression 
> > > because before your patch GEN_RTC would override RTC_CLASS, now it's the
> > > other way around.
> > 
> > Well, previously there was no override ... I think you mean
> > that parisc just completely ignored RTC_CLASS, treating it
> > like junk DNA.
> 
> No, it's a regression.  ...  This turns off the ability to select
> GEN_RTC if you've said yes to RTC_CLASS.  Since RTC_CLASS is currently
> unsupported on parisc, we need to fix that by making the RTC_CLASS
> option unselectable on parisc.

So you affirmed that there was no override, AND that it was
previously treated as junk DNA (ignored).  So just what were
you disagreeing with me about??

I have a hard time calling something a regression which
was never really a supported configuration.  And which
still *JUST WORKS* in those defconfigs ... given all that,
it's hard to argue that something is actually broken.

Kconfig is not about letting Aunt Tillie configure kernels
without being able to shoot herself in the foot.  That
discussion has been had (at length!) before.  Result, we
have a much better kernel config framework ... but still
don't facilitate "Kconfig-4-dummiez" audiences.

- Dave