All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Calfee <stevecalfee@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] Buildroot in use
Date: Thu, 31 Mar 2011 10:13:46 -0700	[thread overview]
Message-ID: <4D94B64A.4000207@gmail.com> (raw)
In-Reply-To: <4D8FCF30.1090209@gmail.com>

Hi Thomas and Peter,

I would like to know if you will accept a patch to implement the following.

On 03/27/11 16:58, Steve Calfee wrote:
> 
> I would like to ask Peter and Thomas what they think of changing the way 
> board support packages are handled. I think that buildroot also needs to 
> support more complete BSP packages which have common desires (booting 
> for USB or booting from NFS) available as options. But this is not great 
> for buildroot because it adds more downloads in a default git pull, it 
> adds bit-rotting code for BSPs, and puts a bigger burden on the core 
> buildroot maintainers.
> 
> What I propose is that BSPs be added just like any other package. A few 
> changes to the buildroot config would allow linking in the new_defconfig 
> for selected packages. The current buildroot config supports selecting 
> toolchain, kernel, u-boot, busybox etc, configs, locations of patches 
> for each, location of external placement of each, etc. As well as handy 
> skeleton updates or additions.  It would be nice if there was a way to 
> add some BSP configuration options - I think the config.in was removed 
> when the bsps were moved from target/device/* to board/manu/*.
> 
> Handling BSPs as packages would enable someone like me to have a github 
> git tree for a bsp, or put in the buildroot download a tar file which 
> can be selected, etc just like any other package. This way when a 
> developer pulls a new version of buildroot he is not also pulling in 
> lots of uninteresting (and possibly quite large) BSPs. But he can select 
> one that is very close to what he wants to use and get a more functional 
> initial package.
> 
> Since a complete set of configurations would be part of the package, bit 
> rot could be slowed. The package would select the latest version of each 
> major component that it was tested and built against. In the future if 
> someone wants to use an unsupported package, he may be able to build it 
> with old configurations and have a stable platform to bring the BSP up 
> to date.
> 
Regards, Steve

      reply	other threads:[~2011-03-31 17:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-15 16:37 [Buildroot] inittab for Busybox Heyendal, Carl
2011-03-15 17:07 ` Thomas Petazzoni
2011-03-15 17:28   ` Charles Krinke
2011-03-15 18:14   ` Heyendal, Carl
2011-03-15 18:22     ` Thomas Petazzoni
2011-03-15 18:32       ` Heyendal, Carl
2011-03-15 20:05         ` Thomas Petazzoni
2011-03-15 20:10           ` Heyendal, Carl
2011-03-16 16:44           ` [Buildroot] Buildroot in use Steve Calfee
2011-03-16 20:08             ` Heyendal, Carl
2011-03-17 12:14             ` William Wagner
2011-03-17 13:53               ` Heyendal, Carl
2011-03-17 17:17                 ` Steve Calfee
2011-03-17 19:42                   ` Heyendal, Carl
2011-03-17 21:50                     ` Steve Calfee
2011-03-18 16:03                       ` Thomas Petazzoni
2011-03-18 16:02                     ` Thomas Petazzoni
2011-03-18 16:01                   ` Thomas Petazzoni
2011-03-17 20:21                 ` Grant Edwards
2011-03-18 15:59               ` [Buildroot] Xtensa support Thomas Petazzoni
2011-03-21 21:18                 ` Piet Delaney
2011-09-20 18:35                   ` Thomas Petazzoni
2011-09-21  4:01                     ` Marc Gauthier
2011-09-21  6:52                       ` Thomas Petazzoni
2011-09-21  8:08                         ` Piet Delaney
2011-03-27 19:19             ` [Buildroot] Buildroot in use Michael J. Hammel
2011-03-27 23:58               ` Steve Calfee
2011-03-31 17:13                 ` Steve Calfee [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D94B64A.4000207@gmail.com \
    --to=stevecalfee@gmail.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.