> Hi, > > 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. >Translation to a more plain language (so to avoid calling both, the original code and the patch too, as "code", or both being "it"): You are suggesting to revert the (wrong) commit 48e94f4fa7b3c3..., and then the whole complete "correct" patch that Martin posted should be applied, not just the first part, but the second part too.>From my prior post, two items remain to be seen:_ clarification from Martin (since I asked a similar question regarding his own email/wording); and _ 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. Regards, Ady.
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); andYes, 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
> 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. > > > -- > MartinSThen 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. Regards, Ady.
Hi, Martin Str|mberg wrote:> 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?I still agree. But while answering Ady's questions i get to a question of my own: Do all six fixed isohdp*.bin variations still fit into 432 bytes ? mbr/Makefile builds among other MBRs: isohdpfx.bin isohdppx.bin isohdpfx_c.bin isohdppx_c.bin isohdpfx_f.bin isohdppx_f.bin Their purpose is explained in the table at http://www.syslinux.org/wiki/index.php?title=Isohybrid#MBR_selection Have a nice day :) Thomas