From: "Hombourger, Cedric" <Cedric_Hombourger@mentor.com>
To: Henning Schild <henning.schild@siemens.com>,
"[ext] Jan Kiszka" <jan.kiszka@siemens.com>
Cc: isar-users <isar-users@googlegroups.com>,
Andreas Reichel <Andreas.Reichel@tngtech.com>
Subject: Re: [PATCH 1/1] meta/ext4-img: refactor to fit current image creation methods
Date: Tue, 26 Feb 2019 12:24:29 +0000 [thread overview]
Message-ID: <1551183868632.90805@mentor.com> (raw)
In-Reply-To: <20190226131218.7ebbdf3e@md1za8fc.ad001.siemens.net>
This is the approach we used for another project :)
We have a wic-extract-parts script but I did not find this approach satisfactory
________________________________________
From: Henning Schild <henning.schild@siemens.com>
Sent: Tuesday, February 26, 2019 1:12 PM
To: [ext] Jan Kiszka
Cc: Hombourger, Cedric; isar-users; Andreas Reichel
Subject: Re: [PATCH 1/1] meta/ext4-img: refactor to fit current image creation methods
Am Tue, 26 Feb 2019 12:56:20 +0100
schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:
> On 26.02.19 12:35, cedric_hombourger@mentor.com wrote:
> > Hi Henning,
> >
> > One use-case on our side is the generation of SWUpdate image. Our
> > helper class uses do_ext4_image to generate the file-system image
> > we later embed into the .swu file
>
> Andreas, how do you address that scenario for upstream SWUpdate
> support?
I guess a valid way would be to have a task after do_wic which will
extract all raw partitions if enabled. It is kind of stupid but if we
can not change wic we better build around and reuse instead of
reimplement.
Henning
> Jan
>
next prev parent reply other threads:[~2019-02-26 12:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-18 13:04 [PATCH 0/1] Refactor ext4 image class claudius.heine.ext
2019-02-18 13:04 ` [PATCH 1/1] meta/ext4-img: refactor to fit current image creation methods claudius.heine.ext
2019-02-19 9:25 ` Henning Schild
2019-02-26 11:35 ` cedric_hombourger
2019-02-26 11:56 ` Jan Kiszka
2019-02-26 12:12 ` Henning Schild
2019-02-26 12:24 ` Hombourger, Cedric [this message]
2019-03-28 9:58 ` Maxim Yu. Osipov
2019-03-28 12:02 ` Hombourger, Cedric
2019-03-29 7:55 ` Adler, Michael
2019-03-29 8:45 ` Maxim Yu. Osipov
2019-02-27 9:28 ` [PATCH 0/1] Refactor ext4 image class Maxim Yu. Osipov
2019-03-28 12:40 ` Maxim Yu. Osipov
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=1551183868632.90805@mentor.com \
--to=cedric_hombourger@mentor.com \
--cc=Andreas.Reichel@tngtech.com \
--cc=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@siemens.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox