| Message ID | 1376598482-9492-1-git-send-email-yann.morin.1998@free.fr |
|---|---|
| State | Accepted |
| Commit | 2b5650cf7ffb6800d56d620aca7377500cc26b37 |
| Headers | show |
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 >
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
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.
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.
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
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.
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
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>
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
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. >
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