grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 08/12] kern: Make grub_error() more verbose


From: Javier Martinez Canillas
Subject: Re: [PATCH v2 08/12] kern: Make grub_error() more verbose
Date: Fri, 6 Mar 2020 13:10:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 3/6/20 12:41 PM, Vladimir 'phcoder' Serbinenko wrote:
> Le ven. 6 mars 2020 à 12:38, Javier Martinez Canillas <address@hidden>
> a écrit :
> 
>> Hello Vladimir,
>>
>> Thanks a lot for your feedback.
>>
>> On 3/5/20 3:22 PM, Vladimir 'phcoder' Serbinenko wrote:
>>> Please evaluate size increase for this. In the past passing file and line
>>> number to grub_dprintf was a huge source of increased Kern and core size
>>>
>>> Le mer. 4 mars 2020 à 13:01, Javier Martinez Canillas <
>> address@hidden>
>>> a écrit :
>>>
>>
>> For a x86_64-pc build with platform=pc on master with and without the
>> patch:
>>
>> $ find -regex '.*\(mod\|img\|exec\)$' -exec du -c {} + | grep total$
>> 2740    total
>>
>> $ find -regex '.*\(mod\|img\|exec\)$' -exec du -c {} + | grep total$
>> 2756    total
>>
>> so in this case the increase is a 0.6% in size.
>>
> This is not the comparison we care about. We care about kernel.img size and
> core.img size for several common configs. And in bytes.
> We have only 31K in mbr gap and every byte counts
> 

Fair. Then I'll only do the comparison for pc platform since for EFI it
doesn't matter due the binary being in the ESP.

I built a core.img with the ext2, part_msdos and biosdisk modules which I
think is a pretty common configuration used. So the following command:

$ ./grub-mkimage --directory ./grub-core/ --prefix '(,msdos1)/grub2' --output 
core.img  --format 'i386-pc' --compression 'auto' 'ext2' 'part_msdos' 'biosdisk'

and I got the following sizes in bytes for the two cases:

without the patch: 25977

with the patch: 26350

So I think my comment still applies, it's just a 1.4% increase (373 bytes).

But also as Daniel said, in most cases the gap between the end of the MBR
and the start of the first partition will be at least 1 MiB due partitions
being aligned to a 1 MiB boundary. It shouldn't be an issue for that case.

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat




reply via email to

[Prev in Thread] Current Thread [Next in Thread]