[U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin

[Julien Castets]

On Sun, Sep 28, 2014 at 8:49 AM, Wolfgang Denk <wd at denx.de> wrote:
> The case where mkimage is taking a single input file is quickly
> becoming a rare corner case.
>
> The recommended way to build U-Boot images is (and has been for years,
> even though marketing for this has been poor) to build FIT images.  In
> this case you typically have several inout files, which are not even
> listed on the mkimage command line, but referenced in the fit-image.its
> file you use.  OK, in this case you could feed the fit-image.its
> through stdin.  But there are other file arguments - like when using
> signed images.
>
> Even if you use the (deprecated) legacy image format, the case of using
> a single input file is not the generic one.  mkimage syntax is:
>
>         mkimage ... -d data_file[:data_file...] ...
>
> and allows to provide several input files - pretty often you need the
> kernel image and the DT blob.  It is also not uncommon to have a
> ramdisk image included.

Thank you so much for you explanations. To tell the truth, I don't
even know what a FIT image is, and even if I saw the usage accepted
several files as input, I didn't search to understand why.


> So if we add support to read from stdin instead from a file where we
> pass the file name as an argument, we should probably do this in a
> consistent way.  It would be a frustrating experience to the end user
> to learn that he can use stdin here but not there - so we would
> probably have to rework all these use cases?  And how should we
> implement this - would a file name "-" mean stdin (1), or should we
> simply pass "/dev/stdin" as file argument (2)?
>
> With (1), we need to change more code, while (2) could probably be
> pretty transparent.

If I understand well, your proposition for (1) would be to use mmap(2)
for everything, but use read(2) for the special case "-".

I'm not sure it is a good idea. The standard input can be handled like
any other file. And note the input could also be a named pipe, that
you won't be able to mmap. With the patch proposed, it would work just
fine.

Also, in the case you're having several files as input, they will be
consumed one after the other. So if the input is "-d
/dev/stdin:/dev/stdin:/dev/stdin", you can give the three files
through stdin.

> You see, even such a simple change like your suggestion needs some
> deeper thought if you want to keep the design consistent.  This is why
> I am asking about your use case, and how it would fit into other
> situations.

Indeed!

-- 
Julien Castets