From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Schwarz,
Konrad (FT RPD CED OES-DE)" <konrad.schwarz@siemens.com>,
"konrad.schwarz@gmail.com" <konrad.schwarz@gmail.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "philmd@linaro.org" <philmd@linaro.org>
Subject: Re: [PATCH 1/1] scripts: Changed potential O(n) file size calculation to O(1)
Date: Fri, 21 Nov 2025 15:10:54 +0100 [thread overview]
Message-ID: <36baba26-5443-4d38-af7f-cea24e00a202@siemens.com> (raw)
In-Reply-To: <AS8PR10MB46806BA652BA28B4BED9884F8AD5A@AS8PR10MB4680.EURPRD10.PROD.OUTLOOK.COM>
On 21.11.25 14:32, Schwarz, Konrad (FT RPD CED OES-DE) wrote:
>> From: Kiszka, Jan (FT RPD CED) <jan.kiszka@siemens.com>
>> Sent: Friday, November 21, 2025 11:16
>> Subject: Re: [PATCH 1/1] scripts: Changed potential O(n) file size calculation to
>> O(1)
>>
>>> scripts/mkemmc.sh | 10 ++++++++--
>>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/scripts/mkemmc.sh b/scripts/mkemmc.sh index
>>> 45dc3f08fa..d2c4e84b16 100755
>>> --- a/scripts/mkemmc.sh
>>> +++ b/scripts/mkemmc.sh
>>> @@ -37,13 +37,19 @@ usage() {
>>> exit "$1"
>>> }
>>>
>>> +file_size() {
>>> + ls_line=$(ls -Hdog "$1") || return
>>
>> This will not suppress the error message when a file does not exist or is not
>> accessible, so:
>>
>> ls_line=$(ls -Hdog "$1" 2>/dev/null) || return
>
> My take on this is:
>
> `ls' is able to produce informative diagnostic messages as it has
> access to `errno'. The additional information, e.g., whether an 'EACCES',
> an `ENOENT' or an `ENOTDIR' error has occurred, should in the majority
> of cases help the user in fixing the underlying problem. I think it would be
> counter-productive to suppress this.
Even if that was true, you should not fold this change into your O(1)
optimization and argue about that separately.
>
> (In fact, one could go further and consider using only the error message
> of `ls' and not provide an own error message at all.
I intentionally wanted to handle the error outside of the low-level
function here. The caller should not care how the size is retrieved -
implementation detail.
But the ls approach still has a major issue: It gives a size for a
directory, rather than failing with "not a readable file".
Jan
> In this case, it would be especially easy to return `ls' status back to
> the script's invoker, by simply invoking `exit' without an argument.)
>
>>
>>> + printf %s\\n "$ls_line" | cut -d\ -f3
>>> + unset ls_line
>>> +}
>>> +
>>> process_size() {
>>> name=$1
>>> image_file=$2
>>> alignment=$3
>>> image_arg=$4
>>> if [ "${image_arg#*:}" = "$image_arg" ]; then
>>> - if ! size=$(wc -c < "$image_file" 2>/dev/null); then
>>> + if ! size=$(file_size "$image_file"); then
>>> echo "Missing $name image '$image_file'." >&2
>>> exit 1
>>> fi
>>> @@ -105,7 +111,7 @@ check_truncation() {
>>> if [ "$image_file" = "/dev/zero" ]; then
>>> return
>>> fi
>>> - if ! actual_size=$(wc -c < "$image_file" 2>/dev/null); then
>>> + if ! actual_size=$(file_size "$image_file"); then
>>> echo "Missing image '$image_file'." >&2
>>> exit 1
>>> fi
>>
>> Thanks,
>> Jan
>>
>> --
>> Siemens AG, Foundational Technologies
>> Linux Expert Center
--
Siemens AG, Foundational Technologies
Linux Expert Center
next prev parent reply other threads:[~2025-11-22 1:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 17:28 [PATCH 1/1] scripts: Changed potential O(n) file size calculation to O(1) konrad.schwarz
2025-11-21 10:16 ` Jan Kiszka
2025-11-21 11:09 ` Daniel P. Berrangé
2025-11-21 14:07 ` Schwarz, Konrad
2025-11-21 13:32 ` Schwarz, Konrad
2025-11-21 14:10 ` Jan Kiszka [this message]
2025-11-21 12:25 ` Paolo Bonzini
[not found] ` <AS8PR10MB4680FED05DB882C0C7751E058AD5A@AS8PR10MB4680.EURPRD10.PROD.OUTLOOK.COM>
[not found] ` <CABgObfb89UUyha3xz5d2MihRkg2WKBTpUOiNMA5o8oPE=MBMyQ@mail.gmail.com>
2025-11-21 14:57 ` Schwarz, Konrad
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=36baba26-5443-4d38-af7f-cea24e00a202@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=konrad.schwarz@gmail.com \
--cc=konrad.schwarz@siemens.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).