[syslinux] [PATCH v2] core: Check size of ldlinux.sys at building time.

[Raphael S Carvalho]

On Thu, Oct 3, 2013 at 11:08 AM, Matt Fleming <matt at console-pimps.org> wrote:
> On Mon, 30 Sep, at 02:14:34AM, Raphael S.Carvalho wrote:
>> From: Raphael S. Carvalho <raphael.scarv at gmail.com>
>>
>> v2: Extract ADV_SIZE automatically from libinstaller/setadv.h.
>>
>> Calc the size of ldlinux.sys from ldlinux.bin, and check if it exceeds the limit.
>> ldlinux.sys must fit between the bootsector and two copies of ADV whose size may vary.
>> Thus, the size of ldlinux.sys can be at most: 65536 - 2 * ADV_SIZE - 512 (limit).
>>
>> Certain file systems (such as BTRFS and UFS2) will rely on ldlinux.sys being installed on the 0-64k range,
>> thus it can't exceed the limit, otherwise the superblock would be corrupted.
>>
>> Signed-off-by: Raphael S. Carvalho <raphael.scarv at gmail.com>
>> Suggested-by: Matt Fleming <matt at console-pimps.org>
>> ---
>>  core/Makefile         |    1 +
>>  core/ldlinux_limit.pl |   80 +++++++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 81 insertions(+), 0 deletions(-)
>>  create mode 100755 core/ldlinux_limit.pl
>
> [...]
>
>> +use File::stat;
>> +use constant DEBUG => (1);
>
> Hehe, might wanna turn debug off ;-)

Agreed, however, on a second thought, that message may be useful for everyone,
so it would be better to turn it on implicitly.
As it dumps the limit, adv_size and the size of ldlinux.sys on a single line.

>
> But the rest of this patch looks good to me. The problem now of course
> is, how do we shrink the core so that this patch doesn't break the
> build?

I will take a look carefully throughout the core to see what could be done.

It's possible to build it correctly by disabling DYNAMIC_DEBUG in devel.mk

It seems we are going to have a problem when the larger ADV_SIZE (4k) arrive.
BTRFS and UFS2 are the only file systems that use the 0-64k range.
Would we need to introduce a new stage as suggested by hpa or modify
the installer?

By modifying the installer, it would only take minor changes, but both
BTRFS and UFS2
wouldn't 'enjoy' the 0-64k range anymore.
On the other hand, we wouldn't need to care about the 0-64k range
anymore (which might be a terrible thing).

>
> --
> Matt Fleming, Intel Open Source Technology Center

Regards,
Raphael S. Carvalho