cleaning up the Kconfig menu structure -- the bigger picture

Tom Rini trini at
Sat Oct 9 05:48:07 EST 2004

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

More information about the Linuxppc-embedded mailing list