"H. Peter Anvin" <[email protected]> writes:
> Eric W. Biederman wrote:
>>>
>>> I think it should be sparsely used, but stuff like simple end markers is
> pretty
>>> much what it's good for.
>>>
>>> The main reason I want to avoid adding another header field is that the
> header
>>> is a finite resource; one of the many poor decisions in its original design
> was
>>> using a 2-byte jump at the top, so address 0x281 is the end of the universe.
>>
>> That was fixed long ago (by having a 4 byte reserved field in the middle) that
>> we can do a two byte jump and then do a farther jump from there to the 16bit
>> code. So as long as we actually use discipline and really reserve
>> the field for a further jump there should be no need for 0x281 being the end
>> of the universe.
>>
>
> That's not the only complication. The thing that concern me more is boot
> loaders using the jump as a length indicator, and there is really very little
> chance to test that out safely, except perhaps by breaking it immediately (by
> adding a 16-byte jump at the end; that way we provide a minimum of overlap for
> boot loader authors.)
The old setup.S had that 16-byte jump in there.
We actually goofed when we added the relocatable bzImage support and
moved the 16bit jump.
> That being said, I don't see any such field (bootsect_kludge could be recycled,
> arguably, and pad2 is three bytes which is enough for a 16-bit jump.)
>
> At the moment, though, that would only push the maximum from 0x281 to 0x290,
> then we run into the next field in struct boot_params. Although this field can
> also be relocated over time, it once again shows that breaking this particular
> limit is nontrivial, and that we're better off trying to avoid pushing it.
> However, with a little discipline I think we can make 0x281 last us for the
> usable lifetime of this format. In the 10 years since the 2.00 format was
> created, we have only added 36 bytes of header, and we have 57 bytes left (plus
> 5 bytes of pad and 6 bytes of recyclable field.) When we get closer to full, if
> we haven't already created a mechanism making field additions obsolete I think
> we would be better off creating a pointer to a secondary header than trying to
> break the limitations involved in the current header format.
I have a hard time believing in discipline when I see the amount of
not invented here and various oddball mistakes (cause by overlooking
things) that seems to go on when extending the format. We never
needed to change the way the command line was passed, and we should
have kept the longer jump where we had it.
If we are going to through and add an additional pointer to a notes section
let's please put a jump in there so we can make the header longer as
we choose.
Pointers really, really, really suck for maintenance of binary formats.
Offsets against a known base are better, but better still is if you can
avoid them entirely. For what we are doing allocating a contiguous piece
of memory or file is not at all unreasonable.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
