[syslinux] where to swap

[Gene Cumm]

On Sun, Mar 26, 2017 at 6:43 AM, Ady Ady via Syslinux
<syslinux at zytor.com> wrote:
>
>> On Sun, Mar 26, 2017 at 09:50:17AM +0000, Ady Ady via Syslinux wrote:
>> > > i wrote:
>> > > > > I think it still has good reason to exist.
>> > >
>> > > Ady wrote:
>> > > > Would you please clarify what do you mean with "it"?
>> > >
>> > > "It" was the code part about
>> > >
>> > >      xor     %cx, %cx        /* Clear EBIOS flag. */
>> > >
>> > > which Martin mentioned as "can be ignored" in the the text which i
>> > > quoted before my statement.
>> ...
>> > _ clarification from Martin (since I asked a similar question regarding
>> > his own email/wording); and
>>
>> Yes, it's the xor %cx, %cx we're talking about. Which might seem
>> overkill now that we know that David's BIOS _didn't_ corrupt CX.
>> And given that space in isohdpfx is very limited (432 bytes) perhaps
>> the right thing might be to not have that xor in there.
>>
>> But then better safe than sorry, and given that there is space _now_,
>> why not?
>>
>>
>> > _ after reverting the (wrong) commit 48e94f4fa7b3c3..., whether the 2
>> > sections of Martin's patch should rather be applied as one commit, or 2
>> > separate commits, or just the first part of the patch should be
>> > applied.
>>
>> The patch in <http://www.syslinux.org/archives/2017-March/025706.html>
>> should be applied after reverting
>> 48e94f4fa7b3c32cbd43b6e57c64bc933f76d059.
>>
>>
>> Except possibly the xor %cx, %cx part as above depending on how
>> causcious or spacesaving you want to be.
>>
>> It seems both Thomas and I think it should remain.
>>
>>
>> --
>> MartinS
>
>
> Then I would suggest:
> 1_ revert the wrong commit;
> 2_ apply the first part of the "right" patch in one commit, as it
> corrects one known bug;
> 3_ apply the second part of the "right" patch in a separated commit,
> which can potentially deal with a different situation than the first
> part of the patch, and, if for some reason additional space is needed
> in the future, it could be considered on its own for future edition.
>

Essentially the approach I took on the isohdpfx branch on my personal repos.
-- 
-Gene