All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 01/15] fs: add genimage infra
Date: Thu, 14 Apr 2016 23:31:54 +0200	[thread overview]
Message-ID: <57100C4A.90903@mind.be> (raw)
In-Reply-To: <87a8kwio80.fsf@dell.be.48ers.dk>

On 04/14/16 10:33, Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
> Hi,
>
>>> # Make sure the genimage dependencies appear in graph-depends
>   >> show-targets:
>   >> @echo $(ROOTFS_GENIMAGE_DEPENDENCIES)
>
>   > But then is it really something that belongs to fs/ ? It really isn't a
>   > filesystem.
>
> No, it is closer to the post-image script. Where do you suggest to move
> it? system/?
>
>
>   >> However, I'm afraid that we're moving a bit too fast after all. There are
>   >> several open issues still:
>   >>
>   >> - Do post-image scripts come before or after genimage?
>   >> - What with the dosfstools/mtools dependency?
>   >> - Should we support genimage.cfg files that are generated from a post-image script?
>   >> - Should we support several genimage.cfg files, producing several images (e.g. a
>   >> NAND and a SD image)?
>   >>
>   >> So, the current approach works well for the bundled defconfigs, but for real
>   >> use cases I think it's a bit too limited to be practical after all.
>
>   > Do we need to support all real use cases? I think we should support the
>   > common use cases, and the more complicated use cases can be handled via
>   > a special post-image script. That's really the general philosophy of
>   > Buildroot IMO: handle the most common cases nicely, and leave enough
>   > extension scripts/hooks to allow people to plug their scripts to handle
>   > the more complicated/specific cases.
>
> Agreed, but it is good to think about the questions Arnout listed to
> think about what is really the common use case.
>
> The definition of the post-image script was to run something at the very
> end, so I think we should do genimage before post-image (even though I
> could imagine use cases for the opposite as well).

  Yes, so eventually we'll have a post-rootfs script...

>
> For the dosfstools/mtools dependencies I think a simple sub option
> pulling them in is most sensible.
>
> Supporting multiple genimage.cfg files (like we do for device_tables /
> post-build / post-image, ..) IMHO makes sense and looks simple to do.

  Well, compared to the really simple solution that Ezequiel has now, I think 
the code will look quite a bit more complicated when there are multiple 
genimage.cfg files.


  Oh, and one more question: should we somehow make sure that the images 
generated by the different scripts don't have the same name?

  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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

  reply	other threads:[~2016-04-14 21:31 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13 20:03 [Buildroot] [PATCH 00/15] Introduce a genimage infra Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 01/15] fs: add " Ezequiel Garcia
2016-04-13 20:24   ` Thomas Petazzoni
2016-04-13 21:32   ` Arnout Vandecappelle
2016-04-13 21:41     ` Thomas Petazzoni
2016-04-14  8:33       ` Peter Korsgaard
2016-04-14 21:31         ` Arnout Vandecappelle [this message]
2016-04-14 21:37           ` Peter Korsgaard
2016-04-14 21:42             ` Yann E. MORIN
2016-04-15  6:45               ` Peter Korsgaard
2016-04-13 21:45     ` Thomas Petazzoni
2016-04-13 22:01       ` Ezequiel Garcia
2016-04-14 21:16       ` Peter Korsgaard
2016-04-14 21:28         ` Arnout Vandecappelle
2016-04-13 20:03 ` [Buildroot] [PATCH 02/15] board/minnowboard-max: Leverage the new " Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 03/15] board/olimex_a20_olinuxino: " Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 04/15] board/wandboard: " Ezequiel Garcia
2016-04-13 20:25   ` Thomas Petazzoni
2016-04-13 22:02     ` Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 05/15] board/firefly: " Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 06/15] board/cubieboard2: " Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 07/15] board/arietta-g25: " Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 08/15] board/imx6ulevk: " Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 09/15] board/galileo: " Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 10/15] board/pandaboard: " Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 11/15] board/boundarydevices: " Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 12/15] board/imx233_olinuxino: " Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 13/15] board/orangepipc: " Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 14/15] board/raspberry*: " Ezequiel Garcia
2016-04-13 20:03 ` [Buildroot] [PATCH 15/15] board/via_imx6_vab820: " Ezequiel Garcia

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=57100C4A.90903@mind.be \
    --to=arnout@mind.be \
    --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.