From: Alper Nebi Yasak <alpernebiyasak@gmail.com>
To: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>,
Dillon Min <dillon.minfei@gmail.com>,
Ivan Mikhaylov <fr0st61te@gmail.com>,
Jonas Karlman <jonas@kwiboo.se>,
Kamil Lulko <kamil.lulko@gmail.com>, Marek Vasut <marex@denx.de>,
Michael Walle <michael@walle.cc>,
Neha Malcom Francis <n-francis@ti.com>,
Patrice Chotard <patrice.chotard@foss.st.com>,
Patrick Delaunay <patrick.delaunay@foss.st.com>,
Peng Fan <peng.fan@nxp.com>,
Philippe Reynes <philippe.reynes@softathome.com>,
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>,
Vikas Manocha <vikas.manocha@st.com>,
u-boot@dh-electronics.com,
uboot-stm32@st-md-mailman.stormreply.com,
U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: [PATCH 0/6] Attempt to enforce standard extensions for build output
Date: Thu, 31 Aug 2023 13:20:29 +0300 [thread overview]
Message-ID: <d4ce17ae-8b84-4c8a-acaa-287549ec23a3@gmail.com> (raw)
In-Reply-To: <CAPnjgZ3ejchoWij6C80nVMVr5iOag3Zazf7O_g_yYcw1U_f+cQ@mail.gmail.com>
On 2023-08-28 20:54 +03:00, Simon Glass wrote:
> Hi Alper,
>
> On Sun, 27 Aug 2023 at 13:17, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>>
>> On 2023-08-24 06:02 +03:00, Simon Glass wrote:
>>> In this early stage of using binman to produce output files, we are mostly
>>> seeing people using common extensions such as '.bin' and '.rom'
>>>
>>> But unusual extensions appear in some places.
>>>
>>> We would like 'buildman -k' to keep the build outputs, but this is hard if
>>> there is no consistency as to the extension used.
>>>
>>> This series adjusts binman to enforce just 4 extensions for output images:
>>>
>>> .bin
>>> .rom
>>> .itb
>>> .img
>>>
>>> Other extensions will produce an error. With this rule observed, buildman
>>> can keep the required files.
>>
>> I dislike this limitation. We know what files we will generate, they are
>> listed in binman dtb, so we can add something like `binman build --ls`
>> to print their names/paths for buildman to preserve them.
>
> Yes, it would be good to have that...
>
> But why do you dislike the limitation? Do you think extensions provide
> useful information? I suppose one problem is that *.bin might pick up
> private blobs that happen to be in the source directory?
I guess my strongest argument is that people already/will have workflows
that depend on certain filenames or extensions, and shouldn't have to
modify binman code (consider that people may be using the PyPI wheels)
to accommodate those when we are already putting the name in the dtb.
I do want some standardization to the U-Boot build outputs though, but
more like a global binman.dts with like u-boot.rom, u-boot-sdmmc.img
images with well-defined TPL, SPL, U-Boot sections that arch-dtsi files
can fill in.
>> Regarding the output directory suggestion, I think the binman outputs
>> (not temporary/intermediate files) should be in the same directory as
>> make outputs
>
> Agreed
>
>> , and the Makefile should default to O=build to achieve the
>> "output dir". I'm not sure if that's going to happen.
>
> I would quite like the 'non-output' file (i.e. things that are not a
> binman image) to appear in a 'binman-work' subdir of the output dir.
> What do you think?
I'd prefer them to go in a tempfile.TemporaryDirectory() and discarded
at the end of a binman run, and a "--tmpdir <path>" option to use a
given directory instead and preserve things for debugging.
next prev parent reply other threads:[~2023-08-31 10:20 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 3:02 [PATCH 0/6] Attempt to enforce standard extensions for build output Simon Glass
2023-08-24 3:02 ` [PATCH 1/6] binman: Require image filenames to have certain extensions Simon Glass
2023-08-24 3:02 ` [PATCH 2/6] buildman: Keep all permitted output files Simon Glass
2023-08-24 14:26 ` Tom Rini
2023-08-24 3:02 ` [PATCH 3/6] buildman: Show progress when regenerating the board.cfg file Simon Glass
2023-08-24 3:02 ` [PATCH 4/6] buildman: Start the clock when the build starts Simon Glass
2023-08-24 3:02 ` [PATCH 5/6] kontron_sl28: Use u-boot-update.bin instead of u-boot.update Simon Glass
2023-08-24 7:35 ` Michael Walle
2023-08-24 3:02 ` [PATCH 6/6] stm32mp15: Use u-boot-spl-stm32.bin instead of u-boot-spl.stm32 Simon Glass
2023-08-24 3:12 ` Marek Vasut
2023-08-24 14:25 ` Tom Rini
2023-08-24 15:09 ` Marek Vasut
2023-08-24 15:14 ` Tom Rini
2023-08-24 15:26 ` Marek Vasut
2023-08-29 16:28 ` Patrick DELAUNAY
2023-09-02 0:09 ` Simon Glass
2023-08-24 7:32 ` [PATCH 0/6] Attempt to enforce standard extensions for build output Michael Walle
2023-08-24 14:43 ` Simon Glass
2023-08-24 14:55 ` Michael Walle
2023-08-24 12:26 ` Neha Malcom Francis
2023-08-24 14:41 ` Simon Glass
2023-08-24 13:38 ` Tom Rini
2023-08-24 14:41 ` Simon Glass
2023-08-24 14:45 ` Tom Rini
2023-08-24 14:49 ` Simon Glass
2023-08-24 15:16 ` Tom Rini
2023-08-27 19:17 ` Alper Nebi Yasak
2023-08-28 17:54 ` Simon Glass
2023-08-28 18:53 ` Tom Rini
2023-08-31 10:20 ` Alper Nebi Yasak [this message]
2023-08-31 19:01 ` Simon Glass
2023-08-31 19:07 ` Tom Rini
2023-08-31 19:22 ` Simon Glass
2023-08-31 19:24 ` Tom Rini
2023-09-01 1:10 ` Simon Glass
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=d4ce17ae-8b84-4c8a-acaa-287549ec23a3@gmail.com \
--to=alpernebiyasak@gmail.com \
--cc=dillon.minfei@gmail.com \
--cc=fr0st61te@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kamil.lulko@gmail.com \
--cc=marex@denx.de \
--cc=michael@walle.cc \
--cc=n-francis@ti.com \
--cc=patrice.chotard@foss.st.com \
--cc=patrick.delaunay@foss.st.com \
--cc=peng.fan@nxp.com \
--cc=philippe.reynes@softathome.com \
--cc=sjg@chromium.org \
--cc=stefan.herbrechtsmeier@weidmueller.com \
--cc=trini@konsulko.com \
--cc=u-boot@dh-electronics.com \
--cc=u-boot@lists.denx.de \
--cc=uboot-stm32@st-md-mailman.stormreply.com \
--cc=vikas.manocha@st.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