[Buildroot] Sample configurations / test suite ?

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Mon Jul 1 07:19:25 UTC 2013

Dear Arnout Vandecappelle,

On Mon, 01 Jul 2013 08:00:02 +0200, Arnout Vandecappelle wrote:

> > What do you think about this? Do you have ideas on how to implement
> > this? Should it be part of the Buildroot tree itself, or something
> > separate? If something separate, how do we keep Buildroot and this
> > separate tree in sync?
>   For both use cases, it makes the most sense if these defconfigs are 
> part of the buildroot tree.

In order to keep those configurations consistent with the rest of
Buildroot, I agree that having them in the Buildroot tree is probably
the easiest option. However, I'm worried about the size of it: I was
not only thinking of defconfigs, but potentially additional artifacts
needed to make the build work.

>   The risk is that the configs/ directory becomes too large and unwieldy 
> (people will have to browse it to find the defconfig they want). So 
> perhaps this calls for changing it into a tree.
>   Personally, I think it makes sense to move the defconfigs into the 
> board/ directory. Many defconfigs already refer into there for kernel 
> configs or specific patches, so it makes sense to put the defconfig in 
> the same place.

Funnily enough, the defconfigs *used* to be in the board/ directory
(which at the time was target/device). We had a discussion back in the
days on whether the defconfigs should remain with their board, or
grouped in the top-level configs/ directory.

and my complaint

That said, after several years, I feel that configs/ was a pretty good
choice, I don't really feel the need of moving things back to board/,
especially considering the change it will cause to all users.

Moreover, I am not sure that those test suite / demos
configurations should be located in the same place as the minimal
defconfigs we have in configs/.

>   And while I'm on this subject, I think the structure of the board 
> directory is not very clear. It would make sense to me to switch to the 
> layout that U-Boot uses: board/<arch>/<soc>/<boardname>/ (although the 
> <soc> level may be optional for us). You can expect people to know what 
> the basic architecture of the processor is, but not always who the vendor 
> is (which is probably why raspberrypi, beaglebone and gnublin don't have 
> a vendor directory). Or sometimes there are multiple vendors for the same 
> board (e.g. Beagleboard and SabreLite).

Hmm, no strong opinion on this one. How many end users know which SoC
the RasberryPi is using?

Best regards,

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.

More information about the buildroot mailing list