Patchwork targets: move target options to their own sub-menu

login
register
mail settings
Submitter Yann E. MORIN
Date Aug. 15, 2013, 8:28 p.m.
Message ID <1376598482-9492-1-git-send-email-yann.morin.1998@free.fr>
Download mbox | patch
Permalink /patch/267427/
State Accepted
Commit 2b5650cf7ffb6800d56d620aca7377500cc26b37
Headers show

Comments

Yann E. MORIN - Aug. 15, 2013, 8:28 p.m.
From: "Yann E. MORIN" <yann.morin.1998@free.fr>

Currently, all target options lie in the top-level menu.
This looks a bit clumsy, since all other options are neatly
folded into their own sematic sub-menus each.

Move the target option into their own sub-menu too.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 arch/Config.in | 4 ++++
 1 file changed, 4 insertions(+)
Arnout Vandecappelle - Aug. 15, 2013, 11:10 p.m.
On 15/08/13 22:28, Yann E. MORIN wrote:
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
>
> Currently, all target options lie in the top-level menu.
> This looks a bit clumsy, since all other options are neatly
> folded into their own sematic sub-menus each.
>
> Move the target option into their own sub-menu too.
>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> ---
>   arch/Config.in | 4 ++++
>   1 file changed, 4 insertions(+)
>
> diff --git a/arch/Config.in b/arch/Config.in
> index 0b5b218..640926a 100644
> --- a/arch/Config.in
> +++ b/arch/Config.in
> @@ -1,3 +1,5 @@
> +menu "Target options"

  I completely agree with the idea - especially in the xconfig, the big 
list of architecture options is extremely annoying. However, the menu 
title is not very clear. How about "Target architecture selection"? Or maybe

Target CPU architecture

   Target CPU architecture family

   Target CPU architecture variant


  Regards,
  Arnout

> +
>   config BR2_ARCH_IS_64
>   	bool
>
> @@ -324,3 +326,5 @@ endif
>   if BR2_xtensa
>   source "arch/Config.in.xtensa"
>   endif
> +
> +endmenu # Target options
>
Thomas De Schampheleire - Aug. 16, 2013, 6:30 a.m.
On Fri, Aug 16, 2013 at 1:10 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 15/08/13 22:28, Yann E. MORIN wrote:
>>

>> diff --git a/arch/Config.in b/arch/Config.in
>> index 0b5b218..640926a 100644
>> --- a/arch/Config.in
>> +++ b/arch/Config.in
>> @@ -1,3 +1,5 @@
>> +menu "Target options"
>
>
>  I completely agree with the idea - especially in the xconfig, the big list
> of architecture options is extremely annoying. However, the menu title is
> not very clear. How about "Target architecture selection"? Or maybe
>
> Target CPU architecture
>
>   Target CPU architecture family
>
>   Target CPU architecture variant
>

Well, I think the menu provides more than just the cpu architecture
choice. It includes other things like ABI choice, binary format
selection, and floating point strategy. The name 'target options' fits
better for these options than anything with 'target cpu architecture'
in it, but I'm open for other suggestions.

While we're at reorganizing the top-level menu: I find the order of
the menus odd. Current order is;
(Target options)
Build options
Toolchain
System configuration
Package selection for the target
Host utilities
Filesystem images
Bootloaders
Kernel
Legacy config options

I think Bootloaders and Kernel should come earlier in the list and
reversed, and Host utilities should be after filesystem images.
My proposal is thus:
(Target options)
Build options
Toolchain
System configuration
Package selection for the target
Kernel
Bootloaders
Filesystem images
Host utilities
Legacy config options

What is your opinion?

Thanks,
Thomas
Yann E. MORIN - Aug. 16, 2013, 6:39 a.m.
Thomas, Arnout, All,

On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
> On Fri, Aug 16, 2013 at 1:10 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> > On 15/08/13 22:28, Yann E. MORIN wrote:
> >>
> 
> >> diff --git a/arch/Config.in b/arch/Config.in
> >> index 0b5b218..640926a 100644
> >> --- a/arch/Config.in
> >> +++ b/arch/Config.in
> >> @@ -1,3 +1,5 @@
> >> +menu "Target options"
> >
> >
> >  I completely agree with the idea - especially in the xconfig, the big list
> > of architecture options is extremely annoying. However, the menu title is
> > not very clear. How about "Target architecture selection"? Or maybe
> >
> > Target CPU architecture
> >
> >   Target CPU architecture family
> >
> >   Target CPU architecture variant
> >
> 
> Well, I think the menu provides more than just the cpu architecture
> choice. It includes other things like ABI choice, binary format
> selection, and floating point strategy. The name 'target options' fits
> better for these options than anything with 'target cpu architecture'
> in it, but I'm open for other suggestions.

Ditto.

> While we're at reorganizing the top-level menu: I find the order of
> the menus odd.
[--SNIP--]
> I think Bootloaders and Kernel should come earlier in the list and
> reversed, and Host utilities should be after filesystem images.
> My proposal is thus:
> (Target options)
> Build options
> Toolchain
> System configuration
> Package selection for the target
> Kernel
> Bootloaders
> Filesystem images
> Host utilities
> Legacy config options
> 
> What is your opinion?

I would even put the kernel before the packages, and bootloaders before
kernel. Ie. I'd use the boot-time order of things:
    (Target options)
    Build options
    Toolchain
    System configuration
    Bootloaders
    Kernel
    Packages selection
    Filesystem images
    Host Utilities
    Legacy config options

Bizzarely enough, moving bootloaders before kernel seems odd... :-/

Regards,
Yann E. MORIN.
Thomas De Schampheleire - Aug. 16, 2013, 10:24 a.m.
On Fri, Aug 16, 2013 at 8:39 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Thomas, Arnout, All,
>
> On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
>> On Fri, Aug 16, 2013 at 1:10 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>> > On 15/08/13 22:28, Yann E. MORIN wrote:
>> >>
> I would even put the kernel before the packages, and bootloaders before
> kernel. Ie. I'd use the boot-time order of things:
>     (Target options)
>     Build options
>     Toolchain
>     System configuration
>     Bootloaders
>     Kernel
>     Packages selection
>     Filesystem images
>     Host Utilities
>     Legacy config options
>
> Bizzarely enough, moving bootloaders before kernel seems odd... :-/


I can follow this boot-time order strategy, but I concur with the
bootloader odditi.
Thomas De Schampheleire - Aug. 16, 2013, 10:30 a.m.
On Fri, Aug 16, 2013 at 12:24 PM, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> On Fri, Aug 16, 2013 at 8:39 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>> Thomas, Arnout, All,
>>
>> On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
>>> On Fri, Aug 16, 2013 at 1:10 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>> > On 15/08/13 22:28, Yann E. MORIN wrote:
>>> >>
>> I would even put the kernel before the packages, and bootloaders before
>> kernel. Ie. I'd use the boot-time order of things:
>>     (Target options)
>>     Build options
>>     Toolchain
>>     System configuration
>>     Bootloaders
>>     Kernel
>>     Packages selection
>>     Filesystem images
>>     Host Utilities
>>     Legacy config options
>>
>> Bizzarely enough, moving bootloaders before kernel seems odd... :-/
>
>
> I can follow this boot-time order strategy, but I concur with the
> bootloader oddity.

[sorry, accidentally hit send button]

Here is a slightly different viewpoint: some users will never touch
the bootloader. However, creating a kernel and rootfs (possibly
attached to the kernel) is very common. This can result in the
following order:

(Target options)
Build options
Toolchain
System configuration
Kernel
Package selection for the target
Filesystem images
Bootloaders
Host Utilities
Legacy config options


By the way: isn't it more logical to put 'Bootloaders' in singular
(Bootloader), since one typically builds only one bootloader, just as
one only builds one kernel...

Best regards,
Thomas
Yann E. MORIN - Aug. 16, 2013, 5:59 p.m.
Thomas, All,

On 2013-08-16 12:30 +0200, Thomas De Schampheleire spake thusly:
> On Fri, Aug 16, 2013 at 12:24 PM, Thomas De Schampheleire
> <patrickdepinguin+buildroot@gmail.com> wrote:
> > On Fri, Aug 16, 2013 at 8:39 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> >> Thomas, Arnout, All,
> >>
> >> On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
> >>> On Fri, Aug 16, 2013 at 1:10 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> >>> > On 15/08/13 22:28, Yann E. MORIN wrote:
> >>> >>
> >> I would even put the kernel before the packages, and bootloaders before
> >> kernel. Ie. I'd use the boot-time order of things:
> >>     (Target options)
> >>     Build options
> >>     Toolchain
> >>     System configuration
> >>     Bootloaders
> >>     Kernel
> >>     Packages selection
> >>     Filesystem images
> >>     Host Utilities
> >>     Legacy config options
> >>
> >> Bizzarely enough, moving bootloaders before kernel seems odd... :-/
> >
> >
> > I can follow this boot-time order strategy, but I concur with the
> > bootloader oddity.
> 
> [sorry, accidentally hit send button]
> 
> Here is a slightly different viewpoint: some users will never touch
> the bootloader. However, creating a kernel and rootfs (possibly
> attached to the kernel) is very common. This can result in the
> following order:
> 
> (Target options)
> Build options
> Toolchain
> System configuration
> Kernel
> Package selection for the target
> Filesystem images
> Bootloaders
> Host Utilities
> Legacy config options

Hey! It looks good to me! :-)
I'll handle this. Thanks!

> By the way: isn't it more logical to put 'Bootloaders' in singular
> (Bootloader), since one typically builds only one bootloader, just as
> one only builds one kernel...

This is two-sided:
  - either you consider what Buildroot has to offer: one kernel, and
    multiple bootloaders;
  - or you consider what the user may want to install on the targe, at
    most one kernel, and at most one bootloader.

I prefer the first option. If at some point in the future Buildroot gets
support for alternative kernels (GNU/Hurd, someone? ;-) ), then we'd
have to s/Kernel/Kernels/.

Consequently, "Package selection for the target" should be a plural
"Packages selection for target".

Regards,
Yann E. MORIN.
Thomas De Schampheleire - Aug. 16, 2013, 7:04 p.m.
On Fri, Aug 16, 2013 at 7:59 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Thomas, All,
>
> On 2013-08-16 12:30 +0200, Thomas De Schampheleire spake thusly:
>>
>> Here is a slightly different viewpoint: some users will never touch
>> the bootloader. However, creating a kernel and rootfs (possibly
>> attached to the kernel) is very common. This can result in the
>> following order:
>>
>> (Target options)
>> Build options
>> Toolchain
>> System configuration
>> Kernel
>> Package selection for the target
>> Filesystem images
>> Bootloaders
>> Host Utilities
>> Legacy config options
>
> Hey! It looks good to me! :-)
> I'll handle this. Thanks!
>

Great!

>> By the way: isn't it more logical to put 'Bootloaders' in singular
>> (Bootloader), since one typically builds only one bootloader, just as
>> one only builds one kernel...
>
> This is two-sided:
>   - either you consider what Buildroot has to offer: one kernel, and
>     multiple bootloaders;
>   - or you consider what the user may want to install on the targe, at
>     most one kernel, and at most one bootloader.
>
> I prefer the first option. If at some point in the future Buildroot gets
> support for alternative kernels (GNU/Hurd, someone? ;-) ), then we'd
> have to s/Kernel/Kernels/.

Ok, agreed.

>
> Consequently, "Package selection for the target" should be a plural
> "Packages selection for target".

'Packages selection' sounds odd to me, I'm not even sure it's proper
English. A 'selection' always refers to a (potential) plural, so I
think 'Package selection' is more correct.

However, why such a long name? Is 'Target packages' not equally clear,
and more in line with the other menu names?

Best regards,
Thomas
Thomas De Schampheleire - Aug. 18, 2013, 7:24 a.m.
On Thu, Aug 15, 2013 at 10:28 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
>
> Currently, all target options lie in the top-level menu.
> This looks a bit clumsy, since all other options are neatly
> folded into their own sematic sub-menus each.
>
> Move the target option into their own sub-menu too.
>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Thomas Petazzoni - Aug. 18, 2013, 4:41 p.m.
Dear Yann E. MORIN,

On Fri, 16 Aug 2013 19:59:07 +0200, Yann E. MORIN wrote:

> This is two-sided:
>   - either you consider what Buildroot has to offer: one kernel, and
>     multiple bootloaders;
>   - or you consider what the user may want to install on the targe, at
>     most one kernel, and at most one bootloader.

"At most one bootloader" is wrong in many situations. On many ARM
platforms, you have two bootloaders. A small first stage bootloader,
and a full-featured second stage bootloader such as U-Boot or Barebox.

On AT91 platforms, you have AT91Bootstrap + U-Boot or Barebox.

On some i.MX platforms, you have mxs-bootlets + U-Boot or Barebox.

On some OMAP platforms, you have X-Loader + U-Boot.

etc, etc.

So clearly, we should keep "Bootloaders" in the plural form.

Best regards,

Thomas
Arnout Vandecappelle - Aug. 19, 2013, 4:33 p.m.
On 16/08/13 08:39, Yann E. MORIN wrote:
> Thomas, Arnout, All,
>
> On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
>> On Fri, Aug 16, 2013 at 1:10 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>> On 15/08/13 22:28, Yann E. MORIN wrote:
>>>>
>>
>>>> diff --git a/arch/Config.in b/arch/Config.in
>>>> index 0b5b218..640926a 100644
>>>> --- a/arch/Config.in
>>>> +++ b/arch/Config.in
>>>> @@ -1,3 +1,5 @@
>>>> +menu "Target options"
>>>
>>>
>>>   I completely agree with the idea - especially in the xconfig, the big list
>>> of architecture options is extremely annoying. However, the menu title is
>>> not very clear. How about "Target architecture selection"? Or maybe
>>>
>>> Target CPU architecture
>>>
>>>    Target CPU architecture family
>>>
>>>    Target CPU architecture variant
>>>
>>
>> Well, I think the menu provides more than just the cpu architecture
>> choice. It includes other things like ABI choice, binary format
>> selection, and floating point strategy. The name 'target options' fits
>> better for these options than anything with 'target cpu architecture'
>> in it, but I'm open for other suggestions.
>
> Ditto.

  I would say that the ABI is part of the CPU architecture - you. An ABI 
choice only exists for compatibility with earlier or different variants 
of the same family. The ABI is typically defined by the CPU designer.

  Other choices in their are (or could be) floating point (neon/vfpv3), 
SIMD extensions, and in the future maybe SoC. All of which I would say 
are CPU architecture options.


>> While we're at reorganizing the top-level menu: I find the order of
>> the menus odd.
> [--SNIP--]
>> I think Bootloaders and Kernel should come earlier in the list and
>> reversed, and Host utilities should be after filesystem images.
>> My proposal is thus:
>> (Target options)
>> Build options
>> Toolchain
>> System configuration
>> Package selection for the target
>> Kernel
>> Bootloaders
>> Filesystem images
>> Host utilities
>> Legacy config options
>>
>> What is your opinion?
>
> I would even put the kernel before the packages, and bootloaders before
> kernel. Ie. I'd use the boot-time order of things:
>      (Target options)
>      Build options
>      Toolchain
>      System configuration
>      Bootloaders
>      Kernel
>      Packages selection
>      Filesystem images
>      Host Utilities
>      Legacy config options
>
> Bizzarely enough, moving bootloaders before kernel seems odd... :-/

  I started to write my own preferred order and it was still different 
:-) So I think there's simply no optimal order. That said, I certainly 
think that the kernel should come before the packages. So I'll ack your 
patch.


  Regards,
  Arnout

 >
>
> Regards,
> Yann E. MORIN.
>

Patch

diff --git a/arch/Config.in b/arch/Config.in
index 0b5b218..640926a 100644
--- a/arch/Config.in
+++ b/arch/Config.in
@@ -1,3 +1,5 @@ 
+menu "Target options"
+
 config BR2_ARCH_IS_64
 	bool
 
@@ -324,3 +326,5 @@  endif
 if BR2_xtensa
 source "arch/Config.in.xtensa"
 endif
+
+endmenu # Target options