Re: cleaning up the Kconfig menu structure -- the bigger picture

[Tom Rini <trini@kernel.crashing.org>]

On Fri, Oct 08, 2004 at 02:39:51PM -0400, Dan Malek wrote:
> 
> On Oct 8, 2004, at 2:02 PM, Tom Rini wrote:
> 
> >But that's what I just described.  Letting the special config options
> >(I don't know if I'd call 85xx_PCI2 "I/O", but it is special) live in
> >platforms/8xx/Kconfig (or ppc/Kconfig.cpm1, or whatever).
> 
> You are conveniently ignoring the 4xx serial port configuration
> options that live in the platforms/4xx/Kconfig right now.  Taking
> debating lessons from dubyah, I guess :-)

No, just that I know Matt wants to see the uart0/uart1 part die and I
bet SERIAL_SICC would be rewritten and moved it was maintained. :)

> If you need change for the sake of change or just because you
> want to disagree with me, then there isn't anything I can do to
> convince you otherwise.  There is precedent from previous
> releases, in the current release with other processors, and from
> extensive experience that you should make you consider my
> suggestions.  I can understand moving the sources to better
> assist the development of code that interacts with these drivers,
> but scattering the unique and interdependent configuration
> options around isn't helpful.

I don't get it.  We do agree that the very specific stuff does indeed
belong somewhere that's obvious to the user, right?  We do agree that
for cpm2, cpm2-specific and not driver related stuff belongs in
platforms/85xx/Kconfig, right?  Are we disagreeing that the non-driver
portions of 8xx_io (and 82xx_io) should just live in syslib/ with
similar functionality bits of other machine types?  And that drivers
should live in drivers/ and asked with other drivers?

> The non-ppc folks updating the
> generic Kconfig files are going to be totally confused by that.

They haven't been confused by all of the other architectures stuff.  In
fact, they've helped clean things up too.

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