cleaning up the Kconfig menu structure -- the bigger picture

cleaning up the Kconfig menu structure -- the bigger picture

[Robert P. J. Day]

   somewhat related to dan malek's posting, but i think part of the 
problem with trying to figure out what the menuconfig menus should 
support is that the relevant options are organized in a confusingly 
haphazard way.

   if you're building a kernel for an 8xx system, obviously you'll 
choose the 8xx processor, at which point naturally a number of other 
kernel config menu entries (dependent on the "8xx" config variable and 
falling off of that) suddenly become visible.  unfortunately, in 
really badly-chosen places.

   consider, first, serial port options.  if you choose 8xx, then 
you'll be presented with the menu choices:

   Device Drivers -->
     Character devices -->
       Serial drivers -->
         CPM SCC/SMC serial port support --> etc, etc.

now, is this the right place for configuring CPM SCC/SMC serial port 
support?  sure, some people might say.  after all, it's serial port 
stuff, it should be under "Serial drivers".  makes perfect sense, 
right?

   in that case, if you wanted to configure "CPM SCC Ethernet", why 
would you go under "MPC8xx CPM Options" rather than the general 
networking menu?  this is clearly inconsistent.

   more to the point, i've always found it a bit strange that selecting 
"8xx" as a processor would suddenly cause the top-level "MPC8xx CPM 
Options" menu to appear, when other 8xx-related stuff was still 
scattered elswewhere throughout the kernel source tree.

   it might make more sense, if you choose "8xx", to have *all* 
8xx-related stuff to suddenly appear under a single top-level menu: 
serial ports, networking, patches, etc.  at least, you'd get to see 
everything in one place, and calculating interdependencies would be 
simpler (no, you can't choose SMC1 to be both a serial port and an 
ethernet, that sort of thing).

   i don't know if this suggestion is feasible but, really, it seems 
clear that the current menu structure is pretty ad hoc and 
disorganized.

   thoughts?

rday

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

[Dan Malek]

On Oct 8, 2004, at 7:16 AM, Robert P. J. Day wrote:

> now, is this the right place for configuring CPM SCC/SMC serial port 
> support?  sure, some people might say.  after all, it's serial port 
> stuff, it should be under "Serial drivers".  makes perfect sense, 
> right?

Not exactly.  At one point we decided to keep the CPM and other 
8xx/82xx/85xx
unique configuration options in a separate set of menus under 
arch/ppc/cpm*
as appropriate.  There may (usually will) be drivers and support unique 
to these
processors that will always simply continue to live there.  We decided 
to not
scatter the configuration options about, placing the sharable drivers 
in the
standard places, but the configuration local.  One reason for this is 
some of
these drivers may be shared by several Freescale processors, as they are
starting to use these peripheral blocks in more varied processors.  The 
basic
drivers are the same, but configuration options and support functions 
may
be different.  These support and configuration options should be 
collected
in a processor type specific place, and set configuration options the 
shared
drivers will use as necessary.

Once again I'll add the observation that people using these processors
have to know how the boards are configured and to select the proper
options.  There is lots of variation among the configurations and I'd 
rather
not build complex configuration menus that try to keep users from
hurting themselves.  The default configuration files are there for a 
reason,
let's use them to assist people (and keep them up to date).

If you are making changes to configuration options, it would be nice if
you would also at least regenerate all default configuration files 
affected
by this (as I do).  At least make an honest attempt at getting it 
correct.

Thanks.

	-- Dan

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

[Robert P. J. Day]

On Fri, 8 Oct 2004, Dan Malek wrote:

> Once again I'll add the observation that people using these 
> processors have to know how the boards are configured and to select 
> the proper options.  There is lots of variation among the 
> configurations and I'd rather not build complex configuration menus 
> that try to keep users from hurting themselves.  The default 
> configuration files are there for a reason, let's use them to assist 
> people (and keep them up to date).

i have no problem with that.  my point was that what are currently 
potentially confusing config menus should be made *simpler*.  i wasn't 
even talking about putting smarts into the config menus to keep people 
from hurting themselves.  i was only talking about putting what 
appeared to be tightly-related config options closer to one another so 
one did not have to bounce from one place to another in the config 
menus to select or deselect related features, that's all.  not a big 
deal for me, it was just an observation.

> If you are making changes to configuration options, it would be nice 
> if you would also at least regenerate all default configuration 
> files affected by this (as I do).  At least make an honest attempt 
> at getting it correct.

been there, done that, thanks.  all of the microcode patch code that 
i've submitted is based on a user selecting that they want *some* 
patch, which is reflected by the config variable CONFIG_UCODE_PATCH.
for all default config files that refer to this variable, they *all* 
contain the line:

# CONFIG_UCODE_PATCH is not set

in short, none of the default config files need to be changed -- they 
will all initially show a config menu with no selected patch.

(what *won't*, of course, be in these default config files is the set 
of option lines for each possible patch, like:

# CONFIG_I2C_SPI_UCODE_PATCH is not set
...
and so on.  but that doesn't matter, since the first time you 
configure and save, they'll be generated.  in short, the default 
config files appear to be just fine.)

rday

p.s.  ironically, i recall just yesterday suggesting that 
soon-to-be-deleted config variables should be removed from those very 
config files, and i was told to just leave them alone.  one does get 
mixed messages on this list sometimes, don't one? :-)

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

[Robert P. J. Day]

On Fri, 8 Oct 2004, Dan Malek wrote:

>
> On Oct 8, 2004, at 11:38 AM, Robert P. J. Day wrote:
>
>> i have no problem with that.  my point was that what are currently 
>> potentially confusing config menus should be made *simpler*.
>
> Thanks.  Just do it as I described.  Keep the configuration scripts 
> localized under the arch/ppc/cpm* directories.

*what* arch/ppc/cpm* directories?

rday

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

[Dan Malek]

On Oct 8, 2004, at 11:38 AM, Robert P. J. Day wrote:

> i have no problem with that.  my point was that what are currently 
> potentially confusing config menus should be made *simpler*.

Thanks.  Just do it as I described.  Keep the configuration scripts 
localized
under the arch/ppc/cpm* directories.


	-- Dan

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

[Tom Rini]

On Fri, Oct 08, 2004 at 07:16:18AM -0400, Robert P. J. Day wrote:

>   somewhat related to dan malek's posting, but i think part of the 
> problem with trying to figure out what the menuconfig menus should 
> support is that the relevant options are organized in a confusingly 
> haphazard way.

I suppose it's confusing from how it used to be, but not so much from a
how everyone else chooses stuff way.  For example...
[snip]
>   consider, first, serial port options.  if you choose 8xx, then 
> you'll be presented with the menu choices:
> 
>   Device Drivers -->
>     Character devices -->
>       Serial drivers -->
>         CPM SCC/SMC serial port support --> etc, etc.

Which is where every other serial driver is (that's been updated to use
the new serial core and make life easier).

[snip]
>   in that case, if you wanted to configure "CPM SCC Ethernet", why 
> would you go under "MPC8xx CPM Options" rather than the general 
> networking menu?  this is clearly inconsistent.

Because the CPM1/CPM2 enet drivers are still waiting to be cleaned up a
bit more, and moved there.  The FEC enet driver that Pantelis wrote
lives in drivers/net/ for example.

>   more to the point, i've always found it a bit strange that selecting 
> "8xx" as a processor would suddenly cause the top-level "MPC8xx CPM 
> Options" menu to appear, when other 8xx-related stuff was still 
> scattered elswewhere throughout the kernel source tree.

That's kinda the opposite direction of where I want things to move.
What, IMHO, should happen is that once the real drivers side of 8xx_io
are moved out into drivers/ we'll really be left with commproc and
microcode, both of which can live in arch/ppc/syslib/ as cpm1_common.c
and cpm1_microcode.c respecivley and we can deal with microcode
questions in arch/ppc/Kconfig where we now source the 8xx_io/Kconfig
file (or, if it really does end up making sense to, and I'm not yet
convinced of this, make platforms/8xx, we can put the question in
platforms/8xx/Kconfig).

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

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

[Robert P. J. Day]

On Fri, 8 Oct 2004, Tom Rini wrote:

> On Fri, Oct 08, 2004 at 07:16:18AM -0400, Robert P. J. Day wrote:
...
>>   in that case, if you wanted to configure "CPM SCC Ethernet", why
>> would you go under "MPC8xx CPM Options" rather than the general
>> networking menu?  this is clearly inconsistent.
>
> Because the CPM1/CPM2 enet drivers are still waiting to be cleaned up a
> bit more, and moved there.  The FEC enet driver that Pantelis wrote
> lives in drivers/net/ for example.

ok, that's cool.

>>   more to the point, i've always found it a bit strange that selecting
>> "8xx" as a processor would suddenly cause the top-level "MPC8xx CPM
>> Options" menu to appear, when other 8xx-related stuff was still
>> scattered elswewhere throughout the kernel source tree.
>
> That's kinda the opposite direction of where I want things to move.
...

i wasn't really arguing for any *particular* rearrangement, just 
arguing for *some* rearrangement that would be more consistent in 
terms of layout, that's all.  and it sounds like it's already 
underway, so i'll shut up about it now.

rday

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

[Dan Malek]

On Oct 8, 2004, at 12:40 PM, Tom Rini wrote:

> Which is where every other serial driver is (that's been updated to use
> the new serial core and make life easier).

How does this make life easier?

> That's kinda the opposite direction of where I want things to move.

That doesn't make sense to those of us with experience using all
of the 8xx/82xx/85xx variants, other processors that may use the
same peripherals (like ColdFire), or with knowledge of yet to be
announce parts.

> What, IMHO, should happen is that once the real drivers side of 8xx_io
> are moved out into drivers/ we'll really be left with commproc and
> microcode, both of which can live in arch/ppc/syslib/ as cpm1_common.c

That's irrelevant to keeping the menu options in a central place.
Maybe it's because I'm old, but keeping the CPM configuration options
in one place on the screen seems to make it easier to think and choose
the proper options.  Remember, there is lots more to the CPM than just
serial ports or Ethernet drivers.  There are drivers floating around 
that
for some mysterious reason never seem to make it into the Linus tree
or out of development trees into other "official" place.

> ....... and we can deal with microcode
> questions in arch/ppc/Kconfig where we now source the 8xx_io/Kconfig
> file ....

There is never any harm in separating logical functions into separate
files.  Using this argument I guess you would like the whole kernel
to just be one big Linux.c file? :-)

>  (or, if it really does end up making sense to, and I'm not yet
> convinced of this, make platforms/8xx, we can put the question in
> platforms/8xx/Kconfig).

I don't know why we don't have the platforms/8xx directory.  We already
have 4xx and 85xx, there are certainly more 8xx boards and 
configurations
than anything else (if all of the 2.4 stuff was actually moved 
forward).  Both
of the 4xx and 85xx have special IO configuration options even though
they have drivers in the standard places.  Your desire of "where you 
want
8xx to move" is against what has been established for other processors,
and of course doesn't make sense to me.

Thanks.

	-- Dan

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

[Tom Rini]

On Fri, Oct 08, 2004 at 01:22:06PM -0400, Dan Malek wrote:

> 
> On Oct 8, 2004, at 12:40 PM, Tom Rini wrote:
> 
> >Which is where every other serial driver is (that's been updated to use
> >the new serial core and make life easier).
> 
> How does this make life easier?

I wasn't clear.  drivers/serial/ makes the life of serial driver writers
easier as all of the stuff people kept c&p'ing from
drivers/char/serial.c is common, and so on.

Having the serial choice in drivers/serial/Kconfig is easier on folks
migrating from other platforms since it's where they would expect it
(since that's where all of the other serial drivers are).  It's
hopefully nothing for people who've done 8xx on 2.4 compared to all of
the other stuff changed in 2.6, but it isn't making life easier for
them.

> >That's kinda the opposite direction of where I want things to move.
> 
> That doesn't make sense to those of us with experience using all
> of the 8xx/82xx/85xx variants, other processors that may use the
> same peripherals (like ColdFire), or with knowledge of yet to be
> announce parts.

I'll agree it's a change, but this is how everyone else works.  For
example, it might make sense to rename platforms/85xx to platforms/cpm2,
and that's where (making up examples) cpm2 microcode updates, errata
config options, enable foolevel/type cache options could go, while
drivers live under drivers/.

IMHO, the biggest reason someone outside the ppc32 community hasn't
yelled about arch/ppc/{8xx,82xx}_io/ is that it wasn't called
arch/ppc/drivers/{8xx,82xx} :)

> >What, IMHO, should happen is that once the real drivers side of 8xx_io
> >are moved out into drivers/ we'll really be left with commproc and
> >microcode, both of which can live in arch/ppc/syslib/ as cpm1_common.c
> 
> That's irrelevant to keeping the menu options in a central place.
> Maybe it's because I'm old, but keeping the CPM configuration options
> in one place on the screen seems to make it easier to think and choose
> the proper options.  Remember, there is lots more to the CPM than just
> serial ports or Ethernet drivers.  There are drivers floating around 
> that
> for some mysterious reason never seem to make it into the Linus tree
> or out of development trees into other "official" place.

But they too should live with with their drivers/ (or net/)
counter-parts, even if they aren't in Linus' tree.

> >....... and we can deal with microcode
> >questions in arch/ppc/Kconfig where we now source the 8xx_io/Kconfig
> >file ....
> 
> There is never any harm in separating logical functions into separate
> files.  Using this argument I guess you would like the whole kernel
> to just be one big Linux.c file? :-)

Fine, arch/ppc/Kconfig.cpm1 if we don't have platforms/8xx/ :)

> > (or, if it really does end up making sense to, and I'm not yet
> >convinced of this, make platforms/8xx, we can put the question in
> >platforms/8xx/Kconfig).
> 
> I don't know why we don't have the platforms/8xx directory.  We already
> have 4xx and 85xx, there are certainly more 8xx boards and 
> configurations
> than anything else (if all of the 2.4 stuff was actually moved 
> forward).

Yes.  But 8xx isn't board.[ch] and mpc<cpu_variant>.[ch], it's
m8xx_setup.c + board.h.  If we can work it out into being more like
85xx and 4xx, that would convince me :)

> Both
> of the 4xx and 85xx have special IO configuration options even though
> they have drivers in the standard places.  Your desire of "where you 
> want
> 8xx to move" is against what has been established for other processors,
> and of course doesn't make sense to me.

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).

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

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

[Dan Malek]

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 :-)  It is more likely we
will see additions to the existing 85xx/Kconfig as it matures
like are needed for 8xx.  You will have to add the configuration
options I mentioned in previous messages, so you may as
well prepare for that now.

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.  The non-ppc folks updating the
generic Kconfig files are going to be totally confused by that.

Thanks.


	-- Dan

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

[Tom Rini]

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/

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

[Dan Malek]

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.  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.

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.

Thanks.


	-- Dan

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

[Tom Rini]

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.

ok.

> 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
http://gate.crashing.org/~trini/

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

[Wolfgang Denk]

In message <85927CE7-196B-11D9-9299-003065F9B7DC@embeddededge.com> Dan Malek wrote:
> 
> I want all of the CPM and 8xx/82xx/85xx configuration to be in
> a common menu, just like it is today.  I don't understand the
...
> 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.

Just for the record: I'm 100% in accord with Dan.

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Though a program be but three lines long,
someday it will have to be maintained."
- The Tao of Programming