[Buildroot] Sample configurations / test suite ?
Arnout Vandecappelle
arnout at mind.be
Mon Jul 1 06:00:02 UTC 2013
On 06/27/13 00:43, Thomas Petazzoni wrote:
> Hello,
>
> Currently, the defconfig that we accept in configs/ are defconfig for
> various hardware platforms that should be as minimal as possible: the
> bootloader(s), the kernel, Busybox, the right filesystem images and
> that's it. Since I've been a fairly strong supporter of this approach,
> I continue to believe it makes sense, since there is no way, for a
> particular board, to decide which software components should or should
> not be part of the default configuration for this board.
>
> However, I am seeing two cases where we would want to have bigger, more
> specific defconfig files:
>
> 1) As part of a test suite. Things like building Xenomai, RTAI,
> building a kernel with the various combination (with or without DT,
> etc.) are not tested by our autobuilders, and we've recently had
> reports of Xenomai being broken for example. Having a set of
> configurations that are interesting to build would be very useful,
> and this set could be extended when we think it is necessary (for
> example after receiving a bug report). Those configurations could
> be built on a daily basis, they could have some custom post-image
> script to verify that the build has generated everything that was
> expected, etc.
>
> 2) As part of a set of demonstration defconfigs. For example, Spenser
> Gilliland has recently posted on his blog a defconfig that
> demonstrates how to use OpenMAX on Raspberry Pi to do
> hardware-accelerated video decoding. Maybe it would make sense to
> have a way of storing those "demonstration" configurations
> somewhere, so that they gain in visibility and can more easily be
> re-used by users.
>
> 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.
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.
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).
But of course, I'm not going to produce patches so I should probably
shut up :-)
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
More information about the buildroot
mailing list