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

On Fri, Oct 08, 2004 at 02:39:51PM -0400, Dan Malek wrote:

On Oct 8, 2004, at 2:02 PM, Tom Rini wrote:

quoted

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/