cleaning up the Kconfig menu structure -- the bigger picture

Tom Rini trini at
Sat Oct 9 07:38:38 EST 2004

On Fri, Oct 08, 2004 at 04:49:17PM -0400, Dan Malek wrote:
> On Oct 8, 2004, at 3:48 PM, Tom Rini wrote:
> >I don't get it.  We do agree that the very specific stuff does indeed
> >belong somewhere that's obvious to the user, right?
> I want all of the CPM and 8xx/82xx/85xx configuration to be in
> a common menu, just like it is today.

That's not exactly how it is, but I see what you're saying.

> I don't understand the
> fascination with syslib/, but if that's where you want things,
> that's fine.


> Drivers that are common to multiple platforms or
> otherwise interact with common subsystems (like uarts and
> network drivers) should be in the standard directories.

No driver should ever live under arch/.  I'll point to the example of
'm32r' which was just merged with arch/m32r/drivers/ and within a week
or so had it all moved properly to drivers/, with help from community
folks.  And let me remind you of drivers/net/fec.c again. :)

> As the discussion started out earlier today, I also don't like
> the configuration options scattered about and in the past
> we have discussed this was not to be the case.  Those of
> us writing the new code or updating existing code all
> thought this was the configuration process, and now today
> you are arguing for something different and are likely to
> implement it that way against our wishes.  Based upon the
> processor type, we should be invoking different Kconfig
> scripts that although may use the same sources have different
> configuration option criteria.  It is significantly easier for
> us to keep those things local for consistent modification,
> and I contend will make it easier to focus on the configuration
> selections when doing so interactively.

I really hate the 'grafted on' feeling 8xx has in the kernel right now.
I know that when the work was started, various upstreams weren't
responsive or didn't care about some embedded platform, but things
have changed.  It does make sense to put 8xx_CPU6 in arch/ppc/
something, and it does make sense to have some obvious menu for 8xx
sub-options, but it doesn't make sense anymore to have serial, enet,
sound, usb, atm, or anything else grouped there anymore.  It's not hard
to get changes upstream.  Andrew listens.  Linus listens.  Other
maintainers listen.  And it just doesn't make sense to me why for 8xx it
all has to be under one menu, but SH can surive with it's serial driver
in drivers/serial/Kconfig and STNIC under drivers/net/Kconfig.

Tom Rini

More information about the Linuxppc-embedded mailing list