Dear Julien,
In message CADF714btdiJT=ccVRBuJk7xUJCgapA-ued=E1J1C0v-Bxa2h=A@mail.gmail.com you wrote:
Without the patch, with mmap:
Thanks for the numbers. So these indeed make no real difference.
I understand the use case, in its globality, is pretty exotic. However, I don't really get why giving /dev/stdin as input is.
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.
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.
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.
Best regards,
Wolfgang Denk