Eric W. Biederman wrote: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.) 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. -hpa -
| Cliffe | Re: [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning |
| Amit K. Arora | [RFC] Heads up on sys_fallocate() |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Andrew Morton | Re: [RFC/PATCH] Documentation of kernel messages |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Radu Rendec | Endianness problem with u32 classifier hash masks |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
git: | |
