From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] fs: allow extra arguments to common tarball extraction
Date: Fri, 8 Jun 2018 19:26:51 +0200 [thread overview]
Message-ID: <20180608172651.GD2090@scaer> (raw)
In-Reply-To: <1148643526.1795245.1528413126545.JavaMail.zimbra@datacom.com.br>
Carlos, All,
On 2018-06-07 20:12 -0300, Carlos Santos spake thusly:
> > From: "Arnout Vandecappelle" <arnout@mind.be>
> > To: "Yann Morin" <yann.morin.1998@free.fr>, "DATACOM" <casantos@datacom.com.br>
> > Cc: "Thomas De Schampheleire" <thomas.de_schampheleire@nokia.com>, "buildroot" <buildroot@buildroot.org>
> > Sent: Thursday, June 7, 2018 6:03:48 PM
> > Subject: Re: [Buildroot] [PATCH] fs: allow extra arguments to common tarball extraction
>
> > On 06-06-18 20:51, Yann E. MORIN wrote:
> >> But my position has always been consistent on this topic: the images
> >> that Buildroot generates only ever covers just "basic" situations, using
> >> a single-filesystem layout. Anything that needs to do a multi-filesystem
> >> layout should be done as a new filesystem. Doing it in a new filesystem
> >> is much more flexible than whatever kconfig option we may ever add. And
> >> since we already have this wonderful flexibility, I don't think it makes
> >> sense to add a new option that duplicates only a very limited subset of
> >> that flexibility. That duplication is not good, IMNSHO...
> >
> > There is (in my even less humble opinion) one way that we can solve this
> > generically: by adding a genimage filesystem. genimage is able to create
> > separate filesystem images for subtrees. so it can cover many use cases in a
> > generic way.
>
> I'm already working on a patch to convert inner-rootfs into a generic
> inner-filesystem macro. I will submit it for comments soon.
Why do you need to do so? You can use the 'rootfs' macro, as I already
explained, and for which I have already sent a patch to add it to the
manual:
https://patchwork.ozlabs.org/patch/926425/
> BTW, it took me some time to understand the dual personality of TARGET_DIR
> in fs/common.mk and the role of BASE_TARGET_DIR. Then I found the line in
> the top Makefile with
>
> TARGET_DIR = $(if $(ROOTFS),$(ROOTFS_$(ROOTFS)_TARGET_DIR),$(BASE_TARGET_DIR))
>
> I understand that this trick avoids changing fs/*/*.mk replacing each
> reference to TARGET_DIR by a ROOTFS_<FOO>_TARGET_DIR but it reduces
> the readability a lot. I'm compelled to restore it to how it was prior
> to commit 7e9870ce32d.
But if you revert that, then TARGET_DIR points to the original target/
directory, which does *not* contain the completely-finalised content.
Please see the commits around that one for the full picture:
git log --oneline 14d43aea0a..543107d390
And see the cover-letter that explains the motivations behind all those
changes:
http://lists.busybox.net/pipermail/buildroot/2018-March/215450.html
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2018-06-08 17:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-03 2:21 [Buildroot] [PATCH] fs: allow extra arguments to common tarball extraction Carlos Santos
2018-06-05 17:23 ` Yann E. MORIN
2018-06-06 12:46 ` Carlos Santos
2018-06-06 18:51 ` Yann E. MORIN
2018-06-07 21:03 ` Arnout Vandecappelle
2018-06-07 23:12 ` Carlos Santos
2018-06-08 7:48 ` Arnout Vandecappelle
2018-06-08 17:34 ` Yann E. MORIN
2018-06-08 19:58 ` Arnout Vandecappelle
2018-06-08 17:26 ` Yann E. MORIN [this message]
2018-06-09 1:06 ` Carlos Santos
2018-06-09 7:31 ` Yann E. MORIN
2018-06-08 17:19 ` Yann E. MORIN
2018-06-08 19:59 ` Arnout Vandecappelle
2018-06-08 21:06 ` Yann E. MORIN
2018-06-10 23:48 ` Carlos Santos
2018-06-09 0:58 ` Carlos Santos
2018-10-26 11:43 ` Peter Korsgaard
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=20180608172651.GD2090@scaer \
--to=yann.morin.1998@free.fr \
--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.