[U-Boot] Kconfig menu layout

[U-Boot] Kconfig menu layout

[Kumar Gala]

In chatting w/Wolfgang on IRC he felt that we should maintain the  
highlevel picking a board implies ARCH and other settings.

However this seems like a lot of boards in one list.. To get a rough  
order of magnitude MAKEALL is ~880 lines.  How can we reduce this to  
make it a bit more manageable?

- k

[U-Boot] Kconfig menu layout

[Jon Smirl]

On Mon, Apr 20, 2009 at 5:11 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
> In chatting w/Wolfgang on IRC he felt that we should maintain the
> highlevel picking a board implies ARCH and other settings.
>
> However this seems like a lot of boards in one list.. To get a rough
> order of magnitude MAKEALL is ~880 lines. ?How can we reduce this to
> make it a bit more manageable?

I'd arrange them by vendor. The vendor kconfig variable doesn't need
to be used in code generation.


>
> - k
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot] Kconfig menu layout

[Kumar Gala]

On Apr 20, 2009, at 5:01 PM, Jon Smirl wrote:

> On Mon, Apr 20, 2009 at 5:11 PM, Kumar Gala  
> <galak@kernel.crashing.org> wrote:
>> In chatting w/Wolfgang on IRC he felt that we should maintain the
>> highlevel picking a board implies ARCH and other settings.
>>
>> However this seems like a lot of boards in one list.. To get a rough
>> order of magnitude MAKEALL is ~880 lines.  How can we reduce this to
>> make it a bit more manageable?
>
> I'd arrange them by vendor. The vendor kconfig variable doesn't need
> to be used in code generation.

Assuming boards/ is grouped by vendor today:

$ ls -1 board/ | wc -l
269

still seems like a long list.

- k

[U-Boot] Kconfig menu layout

[Jon Smirl]

On Mon, Apr 20, 2009 at 7:57 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Apr 20, 2009, at 5:01 PM, Jon Smirl wrote:
>
>> On Mon, Apr 20, 2009 at 5:11 PM, Kumar Gala <galak@kernel.crashing.org>
>> wrote:
>>>
>>> In chatting w/Wolfgang on IRC he felt that we should maintain the
>>> highlevel picking a board implies ARCH and other settings.
>>>
>>> However this seems like a lot of boards in one list.. To get a rough
>>> order of magnitude MAKEALL is ~880 lines. ?How can we reduce this to
>>> make it a bit more manageable?
>>
>> I'd arrange them by vendor. The vendor kconfig variable doesn't need
>> to be used in code generation.
>
> Assuming boards/ is grouped by vendor today:
>
> $ ls -1 board/ | wc -l
> 269
>
> still seems like a long list.

Everyone will know the vendor of their board. You could alphabetize
and break the list into groups. I think there are some entries in
board/ that should be combined and moved into vendor subdirs.

I believe Kconfig is flexible enough you could have two ways of
selecting a board. By arch/cpu or by vendor.

>
> - k
>



-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot] Kconfig menu layout

[Jon Smirl]

On Mon, Apr 20, 2009 at 8:06 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Mon, Apr 20, 2009 at 7:57 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>
>> On Apr 20, 2009, at 5:01 PM, Jon Smirl wrote:
>>
>>> On Mon, Apr 20, 2009 at 5:11 PM, Kumar Gala <galak@kernel.crashing.org>
>>> wrote:
>>>>
>>>> In chatting w/Wolfgang on IRC he felt that we should maintain the
>>>> highlevel picking a board implies ARCH and other settings.
>>>>
>>>> However this seems like a lot of boards in one list.. To get a rough
>>>> order of magnitude MAKEALL is ~880 lines. ?How can we reduce this to
>>>> make it a bit more manageable?
>>>
>>> I'd arrange them by vendor. The vendor kconfig variable doesn't need
>>> to be used in code generation.
>>
>> Assuming boards/ is grouped by vendor today:
>>
>> $ ls -1 board/ | wc -l
>> 269
>>
>> still seems like a long list.
>
> Everyone will know the vendor of their board. You could alphabetize
> and break the list into groups. I think there are some entries in
> board/ that should be combined and moved into vendor subdirs.

There are a lot of boards that could be moved into a vendor subdirs. I
suspect we have less than 100 vendors. Maybe as few as 60.

Don't some of these ads board belong in the freescale dir?
jonsmirl at terra:/home/apps/u-boot/board$ ls *ads* -d
ads5121  adsvix  fads  mpc8260ads  mpc8266ads  mpc8540ads  mpc8560ads
mx1ads  mx31ads

>
> I believe Kconfig is flexible enough you could have two ways of
> selecting a board. By arch/cpu or by vendor.
>
>>
>> - k
>>
>
>
>
> --
> Jon Smirl
> jonsmirl at gmail.com
>



-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot] Kconfig menu layout

[Jerry Van Baren]

Jon Smirl wrote:
> On Mon, Apr 20, 2009 at 8:06 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On Mon, Apr 20, 2009 at 7:57 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>> On Apr 20, 2009, at 5:01 PM, Jon Smirl wrote:
>>>
>>>> On Mon, Apr 20, 2009 at 5:11 PM, Kumar Gala <galak@kernel.crashing.org>
>>>> wrote:
>>>>> In chatting w/Wolfgang on IRC he felt that we should maintain the
>>>>> highlevel picking a board implies ARCH and other settings.
>>>>>
>>>>> However this seems like a lot of boards in one list.. To get a rough
>>>>> order of magnitude MAKEALL is ~880 lines.  How can we reduce this to
>>>>> make it a bit more manageable?
>>>> I'd arrange them by vendor. The vendor kconfig variable doesn't need
>>>> to be used in code generation.
>>> Assuming boards/ is grouped by vendor today:
>>>
>>> $ ls -1 board/ | wc -l
>>> 269
>>>
>>> still seems like a long list.
>> Everyone will know the vendor of their board. You could alphabetize
>> and break the list into groups. I think there are some entries in
>> board/ that should be combined and moved into vendor subdirs.
> 
> There are a lot of boards that could be moved into a vendor subdirs. I
> suspect we have less than 100 vendors. Maybe as few as 60.
> 
> Don't some of these ads board belong in the freescale dir?
> jonsmirl at terra:/home/apps/u-boot/board$ ls *ads* -d
> ads5121  adsvix  fads  mpc8260ads  mpc8266ads  mpc8540ads  mpc8560ads
> mx1ads  mx31ads

I suspect there are also quite a few boards that don't have a vendor 
attached to them or the vendor only has one or two boards in u-boot.  I 
would create a "vendor" named "other" to lump the miscellaneous boards into.

$ ls -1 board/*/*.mk | wc -l
211

OK, that says that, of the 269 directories, 58 are vendor subdirectories 
and 211 are boards that should be stuffed into either an existing vendor 
subdirectory, a new vendor subdirectory, or "other".

(Interesting... vendors appear to have 202 boards, so we have almost as 
many vendor subdirectory boards as top level boards.)
$ ls -1 board/*/*/*.mk | wc -l
202

Best regards,
gvb

[U-Boot] Kconfig menu layout

[Wolfgang Denk]

Dear Jon Smirl,

In message <9e4733910904201712x68658ddfk3c18298deb82bd9f@mail.gmail.com> you wrote:
>
> There are a lot of boards that could be moved into a vendor subdirs. I
> suspect we have less than 100 vendors. Maybe as few as 60.

There is many vendors which have just a single board; also, there are
vendors who prefer to remain anonymous for some reason. Just adding an
additional directory level for a single entry does not make much sense
to me.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When the ax entered the forest, the trees said, "The handle is one of
us!"                                               -- Turkish proverb

[U-Boot] Kconfig menu layout

[Alessandro Rubini]

> There is many vendors which have just a single board;

Like the ST nomadik8815 I maintain.

> Just adding an additional directory level for a single entry does
> not make much sense to me.

So should we leave the nomadik as a single-entry vendor board
or leave it as is? (more nomadik boards will be added over time, but none of
them is in the queue nor will be in the foreseeable months)

/alessandro

[U-Boot] Kconfig menu layout

[Alessandro Rubini]

> So should we leave the nomadik as a single-entry vendor board
> or leave it as is?

Argh!

I mean: leave it alone in its own vendor-dir or move it up one level?
I got the idea vendor dirs were preferred anyway (as suggested by JC),
but Wolfgang's last message suggests the opposite.

Sorry for mistyping
/alessandro

[U-Boot] Kconfig menu layout

[Jon Smirl]

On Tue, Apr 21, 2009 at 10:27 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Jon Smirl,
>
> In message <9e4733910904201712x68658ddfk3c18298deb82bd9f@mail.gmail.com> you wrote:
>>
>> There are a lot of boards that could be moved into a vendor subdirs. I
>> suspect we have less than 100 vendors. Maybe as few as 60.
>
> There is many vendors which have just a single board; also, there are
> vendors who prefer to remain anonymous for some reason. Just adding an
> additional directory level for a single entry does not make much sense
> to me.

My vote would be to require all boards in the board/ directory to be
in a vendor directory.  When you buy the board it is pretty obvious
from the accompanying packaging/manuals who the vendor is. This would
also assign some responsibility to the vendor to maintain the
subdirectory for their products.

Another choice is arch/cpu.

You can use the Kconfig search function Ctrl-F to jump right to a
board name if you know it.


>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> When the ax entered the forest, the trees said, "The handle is one of
> us!" ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -- Turkish proverb
>



-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot] Kconfig menu layout

[Scott Wood]

Jon Smirl wrote:
> My vote would be to require all boards in the board/ directory to be
> in a vendor directory.  When you buy the board it is pretty obvious
> from the accompanying packaging/manuals who the vendor is. 

Companies and product lines get bought, names change...

IMHO, architecture (selected by kconfig, not ARCH=) and CPU family are a 
more robust and managable way of sorting the menu -- and would be 
familiar to those used to configuring Linux.  We could still pull in a 
defconfig from the command line based on a board name alone (in addition 
to the search functionality you mention).

> This would also assign some responsibility to the vendor to maintain the
> subdirectory for their products.

Assuming the vendor cares. :-)

-Scott

[U-Boot] Kconfig menu layout

[Wolfgang Denk]

Dear Jon Smirl,

In message <9e4733910904210841n6c7f0db5s57eee23520dc10a@mail.gmail.com> you wrote:
>
> My vote would be to require all boards in the board/ directory to be
> in a vendor directory.  When you buy the board it is pretty obvious
> from the accompanying packaging/manuals who the vendor is. This would
> also assign some responsibility to the vendor to maintain the
> subdirectory for their products.

No, this is NOT the case. See the examples I quoted, and this is just
a few of them.

In my experience, I tend to search for board names first.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is easier to write an incorrect program than understand a  correct
one.

[U-Boot] Kconfig menu layout

[Kumar Gala]

On Apr 21, 2009, at 3:02 PM, Wolfgang Denk wrote:

> Dear Jon Smirl,
>
> In message  
> <9e4733910904210841n6c7f0db5s57eee23520dc10a@mail.gmail.com> you  
> wrote:
>>
>> My vote would be to require all boards in the board/ directory to be
>> in a vendor directory.  When you buy the board it is pretty obvious
>> from the accompanying packaging/manuals who the vendor is. This would
>> also assign some responsibility to the vendor to maintain the
>> subdirectory for their products.
>
> No, this is NOT the case. See the examples I quoted, and this is just
> a few of them.
>
> In my experience, I tend to search for board names first.

So back to the root of my question, do we just have one really long  
list of board names?

- k

[U-Boot] Kconfig menu layout

[Wolfgang Denk]

Dear Kumar Gala,

In message <93A8F58D-8C13-4F72-AFF3-CF4FDF9A3CFA@kernel.crashing.org> you wrote:
> 
> > In my experience, I tend to search for board names first.
> 
> So back to the root of my question, do we just have one really long  
> list of board names?

I'm not an expert for the capabilities of Kconfig, but one looong list
with hundrets of entries clearly makes no sense. We obviously need sum
grouping / structuring.

IMHO there should be several options:

- for those who look for a board name, we should support this,
  probably wih an initial selection by the first letter (case
  insensitive) of the board name.

  like this:	=> board name => M => MPC837XERDB

- alternatively, it should be possible to restrict the choice by
  selecting first processor architecture (ARM, PowerPC, MIPS, ...),
  then CPU (family) name, then board names.

  like this:	=> Architecture => PPC => MPC83xx => MPC837XERDB

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Severe culture shock results when experts from another protocol suite
[...] try to read OSI documents. The term "osified" is used to  refer
to  such  documents. [...] Any relationship to the word "ossified" is
purely intentional.                                - Marshall T. Rose

[U-Boot] Kconfig menu layout

[Kumar Gala]

On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message <93A8F58D-8C13-4F72-AFF3- 
> CF4FDF9A3CFA at kernel.crashing.org> you wrote:
>>
>>> In my experience, I tend to search for board names first.
>>
>> So back to the root of my question, do we just have one really long
>> list of board names?
>
> I'm not an expert for the capabilities of Kconfig, but one looong list
> with hundrets of entries clearly makes no sense. We obviously need sum
> grouping / structuring.
>
> IMHO there should be several options:
>
> - for those who look for a board name, we should support this,
>  probably wih an initial selection by the first letter (case
>  insensitive) of the board name.
>
>  like this:	=> board name => M => MPC837XERDB
>
> - alternatively, it should be possible to restrict the choice by
>  selecting first processor architecture (ARM, PowerPC, MIPS, ...),
>  then CPU (family) name, then board names.
>
>  like this:	=> Architecture => PPC => MPC83xx => MPC837XERDB

I vote for the second one.

Now I'll ask what the location of "defconfig"s should be?

- k

[U-Boot] Kconfig menu layout

[Jon Smirl]

On Tue, Apr 21, 2009 at 5:05 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:
>
>> Dear Kumar Gala,
>>
>> In message <93A8F58D-8C13-4F72-AFF3-CF4FDF9A3CFA@kernel.crashing.org> you
>> wrote:
>>>
>>>> In my experience, I tend to search for board names first.
>>>
>>> So back to the root of my question, do we just have one really long
>>> list of board names?
>>
>> I'm not an expert for the capabilities of Kconfig, but one looong list
>> with hundrets of entries clearly makes no sense. We obviously need sum
>> grouping / structuring.
>>
>> IMHO there should be several options:
>>
>> - for those who look for a board name, we should support this,
>> ?probably wih an initial selection by the first letter (case
>> ?insensitive) of the board name.
>>
>> ?like this: ? ? => board name => M => MPC837XERDB

You can search for the board name in Kconfig using Ctrl-F and then put
in a string
This works on the kernel too.

>>
>> - alternatively, it should be possible to restrict the choice by
>> ?selecting first processor architecture (ARM, PowerPC, MIPS, ...),
>> ?then CPU (family) name, then board names.
>>
>> ?like this: ? ? => Architecture => PPC => MPC83xx => MPC837XERDB
>
> I vote for the second one.
>
> Now I'll ask what the location of "defconfig"s should be?
>
> - k
>



-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot] Kconfig menu layout

[Wolfgang Denk]

Dear Jon Smirl,

In message <9e4733910904211533s58df5764na715986b36824891@mail.gmail.com> you wrote:
>
> >> - for those who look for a board name, we should support this,
> >> ?probably wih an initial selection by the first letter (case
> >> ?insensitive) of the board name.
> >>
> >> ?like this: ? ? => board name => M => MPC837XERDB
>
> You can search for the board name in Kconfig using Ctrl-F and then put
> in a string
> This works on the kernel too.

Ctrl-F? In which exact envrionment does this work? With "make config"?
"make menuconfig" ?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
CONSUMER NOTICE:  Because  of  the  "Uncertainty  Principle,"  It  Is
Impossible  for  the  Consumer  to  Find  Out  at  the Same Time Both
Precisely Where This Product Is and How Fast It Is Moving.

[U-Boot] Kconfig menu layout

[Jon Smirl]

On Tue, Apr 21, 2009 at 7:14 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Jon Smirl,
>
> In message <9e4733910904211533s58df5764na715986b36824891@mail.gmail.com> you wrote:
>>
>> >> - for those who look for a board name, we should support this,
>> >> ?probably wih an initial selection by the first letter (case
>> >> ?insensitive) of the board name.
>> >>
>> >> ?like this: ? ? => board name => M => MPC837XERDB
>>
>> You can search for the board name in Kconfig using Ctrl-F and then put
>> in a string
>> This works on the kernel too.
>
> Ctrl-F? In which exact envrionment does this work? With "make config"?
> "make menuconfig" ?

I see now that Ctrl-F doesn't work everywhere. Try it in 'make xconfig'


-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot] Kconfig menu layout

[Ben Warren]

Jon Smirl wrote:
> On Tue, Apr 21, 2009 at 7:14 PM, Wolfgang Denk <wd@denx.de> wrote:
>   
>> Dear Jon Smirl,
>>
>> In message <9e4733910904211533s58df5764na715986b36824891@mail.gmail.com> you wrote:
>>     
>>>>> - for those who look for a board name, we should support this,
>>>>>  probably wih an initial selection by the first letter (case
>>>>>  insensitive) of the board name.
>>>>>
>>>>>  like this:     => board name => M => MPC837XERDB
>>>>>           
>>> You can search for the board name in Kconfig using Ctrl-F and then put
>>> in a string
>>> This works on the kernel too.
>>>       
>> Ctrl-F? In which exact envrionment does this work? With "make config"?
>> "make menuconfig" ?
>>     
>
> I see now that Ctrl-F doesn't work everywhere. Try it in 'make xconfig'
>
>   
I don't want to ignite a flame war, but IMHO 'make menuconfig' is the 
one we should be optimizing towards.

What's the objection again to having the user set ARCH before running 
this, or at least to using ARCH as the first sort key?

regards,
Ben

[U-Boot] Kconfig menu layout

[Robert Schwebel]

On Tue, Apr 21, 2009 at 07:22:31PM -0400, Jon Smirl wrote:
> On Tue, Apr 21, 2009 at 7:14 PM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Jon Smirl,
> >
> > In message <9e4733910904211533s58df5764na715986b36824891@mail.gmail.com> you wrote:
> >>
> >> >> - for those who look for a board name, we should support this,
> >> >> ?probably wih an initial selection by the first letter (case
> >> >> ?insensitive) of the board name.
> >> >>
> >> >> ?like this: ? ? => board name => M => MPC837XERDB
> >>
> >> You can search for the board name in Kconfig using Ctrl-F and then put
> >> in a string
> >> This works on the kernel too.
> >
> > Ctrl-F? In which exact envrionment does this work? With "make config"?
> > "make menuconfig" ?
> 
> I see now that Ctrl-F doesn't work everywhere. Try it in 'make xconfig'

Searching in 'make menuconfig' works with "/", like with every good unix
tool.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] Kconfig menu layout

[Wolfgang Denk]

Dear Kumar,

In message <AEA791B2-2BC0-49F7-9152-ACF6CA5671DC@kernel.crashing.org> you wrote:
> 
> > I'm not an expert for the capabilities of Kconfig, but one looong list
> > with hundrets of entries clearly makes no sense. We obviously need sum
> > grouping / structuring.
> >
> > IMHO there should be several options:
> >
> > - for those who look for a board name, we should support this,
> >  probably wih an initial selection by the first letter (case
> >  insensitive) of the board name.
> >
> >  like this:	=> board name => M => MPC837XERDB
> >
> > - alternatively, it should be possible to restrict the choice by
> >  selecting first processor architecture (ARM, PowerPC, MIPS, ...),
> >  then CPU (family) name, then board names.
> >
> >  like this:	=> Architecture => PPC => MPC83xx => MPC837XERDB
> 
> I vote for the second one.

You misunderstant what I meant. I don't think of havon one or the
other of these options, but of offering *both* of them, so the user
can chose one of the ways, whatever suits best for his current
situation.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
SW engineering is a race between programmers trying  to  make  better
idiot-proof programs and the universe producing greater idiots.

[U-Boot] Kconfig menu layout

[Kumar Gala]

On Apr 21, 2009, at 5:59 PM, Wolfgang Denk wrote:

> Dear Kumar,
>
> In message <AEA791B2-2BC0-49F7-9152- 
> ACF6CA5671DC at kernel.crashing.org> you wrote:
>>
>>> I'm not an expert for the capabilities of Kconfig, but one looong  
>>> list
>>> with hundrets of entries clearly makes no sense. We obviously need  
>>> sum
>>> grouping / structuring.
>>>
>>> IMHO there should be several options:
>>>
>>> - for those who look for a board name, we should support this,
>>> probably wih an initial selection by the first letter (case
>>> insensitive) of the board name.
>>>
>>> like this:	=> board name => M => MPC837XERDB
>>>
>>> - alternatively, it should be possible to restrict the choice by
>>> selecting first processor architecture (ARM, PowerPC, MIPS, ...),
>>> then CPU (family) name, then board names.
>>>
>>> like this:	=> Architecture => PPC => MPC83xx => MPC837XERDB
>>
>> I vote for the second one.
>
> You misunderstant what I meant. I don't think of havon one or the
> other of these options, but of offering *both* of them, so the user
> can chose one of the ways, whatever suits best for his current
> situation.

Oh, I dont know if we can do that in Kconfig w/o duplicating the  
option which I think Kconfig would get unhappy about.

- k

[U-Boot] Kconfig menu layout (multiple ways to show the same Kconfig configs?)

[Kumar Gala]

On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message <93A8F58D-8C13-4F72-AFF3- 
> CF4FDF9A3CFA at kernel.crashing.org> you wrote:
>>
>>> In my experience, I tend to search for board names first.
>>
>> So back to the root of my question, do we just have one really long
>> list of board names?
>
> I'm not an expert for the capabilities of Kconfig, but one looong list
> with hundrets of entries clearly makes no sense. We obviously need sum
> grouping / structuring.
>
> IMHO there should be several options:
>
> - for those who look for a board name, we should support this,
>  probably wih an initial selection by the first letter (case
>  insensitive) of the board name.
>
>  like this:	=> board name => M => MPC837XERDB
>
> - alternatively, it should be possible to restrict the choice by
>  selecting first processor architecture (ARM, PowerPC, MIPS, ...),
>  then CPU (family) name, then board names.
>
>  like this:	=> Architecture => PPC => MPC83xx => MPC837XERDB

Sam,

We are looking at moving u-boot to use Kconfig and was wondering if  
you could possible tell us if its possible to represent the same  
Kconfig 'config' options via two different menu schemes.  We have a  
list of boards that will be 'config' options.  We'd like to have it in  
one 'menu' that is just a long list of boards.  The other would be a  
smaller subset that you "filter" based on selecting an Arch & Subarch.

is something like this possible?

- k

[U-Boot] Kconfig menu layout (multiple ways to show the same Kconfig configs?)

[Sam Ravnborg]

On Wed, Apr 22, 2009 at 07:44:48AM -0500, Kumar Gala wrote:
> 
> On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:
> 
> >Dear Kumar Gala,
> >
> >In message <93A8F58D-8C13-4F72-AFF3- 
> >CF4FDF9A3CFA at kernel.crashing.org> you wrote:
> >>
> >>>In my experience, I tend to search for board names first.
> >>
> >>So back to the root of my question, do we just have one really long
> >>list of board names?
> >
> >I'm not an expert for the capabilities of Kconfig, but one looong list
> >with hundrets of entries clearly makes no sense. We obviously need sum
> >grouping / structuring.
> >
> >IMHO there should be several options:
> >
> >- for those who look for a board name, we should support this,
> > probably wih an initial selection by the first letter (case
> > insensitive) of the board name.
> >
> > like this:	=> board name => M => MPC837XERDB
> >
> >- alternatively, it should be possible to restrict the choice by
> > selecting first processor architecture (ARM, PowerPC, MIPS, ...),
> > then CPU (family) name, then board names.
> >
> > like this:	=> Architecture => PPC => MPC83xx => MPC837XERDB
> 
> Sam,
> 
> We are looking at moving u-boot to use Kconfig and was wondering if  
> you could possible tell us if its possible to represent the same  
> Kconfig 'config' options via two different menu schemes.  We have a  
> list of boards that will be 'config' options.  We'd like to have it in  
> one 'menu' that is just a long list of boards.  The other would be a  
> smaller subset that you "filter" based on selecting an Arch & Subarch.

Kconfig does not allow you to duplicate a config entry in two menus
in a way that is usefull here.
You want to use the same name, prompt and help text in both menus.

I think the solution is to have a filter part and a "list all boards"
part.
Then the filter part can be used to make the board list smaller.

Below is a quick mock-up of the idea.
I used CPU + INTERFACE - reading the above I should have used
Arch + SubArch but you get the idea.

If you decide to do something like this then hide most of this
in a separate file and include it.

	Sam


choice SHOW_CPU
	prompt "What CPU?"
	default SHOW_CPU_ALL

config SHOW_CPU_ALL
	bool "Show all cpus"
	select CPU_ARM
	select CPU_POWERPC
	select CPU_AVR32

config SHOW_CPU_ARM
	bool "Show only ARM"
	select CPU_ARM

config SHOW_CPU_POPWERPC
	bool "Show only PowerPC"
	select CPU_POWERPC

config SHOW_CPU_AVR32
	bool "Show only AVR32"
	select CPU_AVR32

endchoice

config CPU_ARM
	bool
config CPU_POWERPC
	bool
config CPU_AVR32
	bool

choice SHOW_INTERFACE_ALL
	tristate "Which interfaces?"
	default SHOW_INTERFACE_ALL

config SHOW_INTERFACE_ALL
	bool "All interfaces"
	select INTERFACE_NONE
	select INTERFACE_USB
	select INTERFACE_CAN

config SHOW_INTERFACE_NONE
	bool "No interfaces!?!?!"
	select INTERFACE_NONE

config SHOW_INTERFACE_USB
	bool "USB"
	select INTERFACE_USB

config SHOW_INTERFACE_CAN
	bool "CAN"
	select INTERFACE_CAN
endchoice

config INTERFACE_NONE
	bool
config INTERFACE_USB
	bool
config INTERFACE_CAN
	bool

config ARM_BOARD_A1
	bool "A1 - not-fancy ARM based board"
	depends on CPU_ARM
	depends on INTERFACE_NONE
	help
	  This is the super fancy ARM based boards

config ARM_BOARD_A2
	bool "A1 - USB ARM based board"
	depends on CPU_ARM
	depends on INTERFACE_USB
	help
	  This is the super fancy ARM based boards

config ARM_BOARD_A3
	bool "A1 - CAN+USB ARM based board"
	depends on CPU_ARM
	depends on INTERFACE_CAN || INTERFACE_USB
	help
	  This is the super fancy ARM based boards


config PPC_BOARD_A1
	bool "P1 - not-fancy PPC based board"
	depends on CPU_POWERPC
	depends on INTERFACE_NONE
	help
	  This is the fancy PopwerPC based board

config PPC_BOARD_USB10
	bool "USB - PopwerPC based USB hub"
	depends on CPU_POWERPC
	depends on INTERFACE_USB
	help
	  The 20 port USB hub with monitoring facilities

config AVR32_CAN
	bool "CAN Monitor based on AVR32"
	depends on CPU_AVR32
	depends on INTERFACE_CAN
	help
	  CAN monitor for 10 CAN simultaneously channels



> 
> is something like this possible?
> 
> - k

[U-Boot] Kconfig menu layout (multiple ways to show the same Kconfig configs?)

[Sam Ravnborg]

On Wed, Apr 22, 2009 at 07:44:48AM -0500, Kumar Gala wrote:
> 
> On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:
> 
> >Dear Kumar Gala,
> >
> >In message <93A8F58D-8C13-4F72-AFF3- 
> >CF4FDF9A3CFA at kernel.crashing.org> you wrote:
> >>
> >>>In my experience, I tend to search for board names first.
> >>
> >>So back to the root of my question, do we just have one really long
> >>list of board names?
> >
> >I'm not an expert for the capabilities of Kconfig, but one looong list
> >with hundrets of entries clearly makes no sense. We obviously need sum
> >grouping / structuring.
> >
> >IMHO there should be several options:
> >
> >- for those who look for a board name, we should support this,
> > probably wih an initial selection by the first letter (case
> > insensitive) of the board name.
> >
> > like this:	=> board name => M => MPC837XERDB
> >
> >- alternatively, it should be possible to restrict the choice by
> > selecting first processor architecture (ARM, PowerPC, MIPS, ...),
> > then CPU (family) name, then board names.
> >
> > like this:	=> Architecture => PPC => MPC83xx => MPC837XERDB
> 
> Sam,
> 
> We are looking at moving u-boot to use Kconfig and was wondering if  
> you could possible tell us if its possible to represent the same  
> Kconfig 'config' options via two different menu schemes.  We have a  
> list of boards that will be 'config' options.  We'd like to have it in  
> one 'menu' that is just a long list of boards.  The other would be a  
> smaller subset that you "filter" based on selecting an Arch & Subarch.
> 
> is something like this possible?

Hi Kumar.

Was my input useable or just pure rubbish?

	Sam

[U-Boot] Kconfig menu layout (multiple ways to show the same Kconfig configs?)

[Kumar Gala]

On May 1, 2009, at 6:47 AM, Sam Ravnborg wrote:

> On Wed, Apr 22, 2009 at 07:44:48AM -0500, Kumar Gala wrote:
>>
>> On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:
>>
>>> Dear Kumar Gala,
>>>
>>> In message <93A8F58D-8C13-4F72-AFF3-
>>> CF4FDF9A3CFA at kernel.crashing.org> you wrote:
>>>>
>>>>> In my experience, I tend to search for board names first.
>>>>
>>>> So back to the root of my question, do we just have one really long
>>>> list of board names?
>>>
>>> I'm not an expert for the capabilities of Kconfig, but one looong  
>>> list
>>> with hundrets of entries clearly makes no sense. We obviously need  
>>> sum
>>> grouping / structuring.
>>>
>>> IMHO there should be several options:
>>>
>>> - for those who look for a board name, we should support this,
>>> probably wih an initial selection by the first letter (case
>>> insensitive) of the board name.
>>>
>>> like this:	=> board name => M => MPC837XERDB
>>>
>>> - alternatively, it should be possible to restrict the choice by
>>> selecting first processor architecture (ARM, PowerPC, MIPS, ...),
>>> then CPU (family) name, then board names.
>>>
>>> like this:	=> Architecture => PPC => MPC83xx => MPC837XERDB
>>
>> Sam,
>>
>> We are looking at moving u-boot to use Kconfig and was wondering if
>> you could possible tell us if its possible to represent the same
>> Kconfig 'config' options via two different menu schemes.  We have a
>> list of boards that will be 'config' options.  We'd like to have it  
>> in
>> one 'menu' that is just a long list of boards.  The other would be a
>> smaller subset that you "filter" based on selecting an Arch &  
>> Subarch.
>>
>> is something like this possible?
>
> Hi Kumar.
>
> Was my input useable or just pure rubbish?

Its usable.. one question I had was if you ever gave thought to having  
a 'config' type that was only for internal dependencies and didn't  
show up in the resulting .config.

- k

[U-Boot] Kconfig menu layout

[Wolfgang Denk]

Dear Jon Smirl,

In message <9e4733910904201706u58387d5fod231dd4b8ac88d74@mail.gmail.com> you wrote:
>
> Everyone will know the vendor of their board. You could alphabetize

Really? So who is the board vendor for the MPC8360 board? Freescale or
Logic PD?  And who is the vendor for the ADS5121? Freescale or STX?

Board names are much better, IMO.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We shall reach greater and greater platitudes of achievement."
- Richard J. Daley

[U-Boot] Kconfig menu layout

[Jon Smirl]

On Tue, Apr 21, 2009 at 10:25 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Jon Smirl,
>
> In message <9e4733910904201706u58387d5fod231dd4b8ac88d74@mail.gmail.com> you wrote:
>>
>> Everyone will know the vendor of their board. You could alphabetize
>
> Really? So who is the board vendor for the MPC8360 board? Freescale or
> Logic PD? ?And who is the vendor for the ADS5121? Freescale or STX?

Read the box when you take the board out.

-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot] Kconfig menu layout

[Wolfgang Denk]

Dear Jon Smirl,

In message <9e4733910904210833u79f3d4dfv2db744916246222e@mail.gmail.com> you wrote:
> On Tue, Apr 21, 2009 at 10:25 AM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Jon Smirl,
> >
> > In message <9e4733910904201706u58387d5fod231dd4b8ac88d74@mail.gmail.com>
> you wrote:
> >>
> >> Everyone will know the vendor of their board. You could alphabetize
> >
> > Really? So who is the board vendor for the MPC8360 board? Freescale or
> > Logic PD? ?And who is the vendor for the ADS5121? Freescale or STX?
> 
> Read the box when you take the board out.

That doesn't help you. The boards are manufactured by Logic PD resp.
STX, but they are the official Freescale eval boards. You can buy
them here or there, or through an unrelated distributor - so who is
the "vendor"?

Or should  the "ebvbeagle" board I buy from EBV go under "env" or
under "ti" - or, hey, is "omap3" the vendor?

The "vendor" concept is helpful sometimes, but generally useful here.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Another dream that failed.  There's nothing sadder.
	-- Kirk, "This side of Paradise", stardate 3417.3