[syslinux] isohybrid question

[Thomas Schmitt]

Hi,

hpa wrote:
> The big problem with isohybrid support in a third-party tool is that the
> isohybrid code is still very much subject to change, since it is still
> somewhat new code.
>
> There were some very heated
> exchanges between myself and the xorriso maintainer because I needed a
> bug fix in the stub code -- despite that I had previously warned that
> that might be happening.

We were technically not d'accord but i'd say
"very heated" looks different. :))

In may 2009 we discussed the problem in two
threads
  http://syslinux.zytor.com/archives/files/2009-May/012373.html
  http://syslinux.zytor.com/archives/files/2009-May/012561.html

I finally accepted that my built-in MBR generator
was obsolete, but then you found a way to keep it
alive for a while:

http://syslinux.zytor.com/archives/files/2009-May/012581.html
>> The *new* isohybrid can work with *old* isolinux.bin (at your request, I
>> might add); what I can't make work is the other way around.

http://syslinux.zytor.com/archives/files/2009-May/012588.html
>> Turns out I can, after all.  It's a total hack, but it should work.
>> You need to argue with me more often.  It seems to make me think.


We discussed a better architecture:

http://syslinux.zytor.com/archives/files/2009-May/012583.html
hpa:
>> What I'm thinking of doing is to add a piece of C code for this.  If you
>> have suggestions as to the interface, that would be appreciated.

I proposed to have several MBR templates ready
which each know 1 to 10 magic numbers for which
they are valid.

http://syslinux.zytor.com/archives/files/2009-May/012593.html
>> Proposal of a struct which contains parameters
>> and results:
>>   struct isohybrid_par {
>> [...]
>>
>> I volunteer to do those tasks which don't require
>> deep SYSLINUX knowledge.
>> 
>> Probably i can translate isohybrid 3.81 to
>> above C sketch. But this translation would have
>> to be checked by a skilled reviewer. So possibly
>> it is simpler if that reviewer makes the
>> translation himself.
>> 
>> Just decide and give me clear orders. :))

Obviously we both had other things to do.

My offer to help maintaining a unified
isohybrid code base is still valid.

------------------------------------------------

> One huge potential advantage of doing the isohybrid code in a filesystem
> generator is that it might be possible to avoid the "offset" problems by
> having two copies of the metadata.

Two PVDs, two El-Toritos and two directory trees
which bear the different addresses of the same
data blocks in /dev/sdb resp. /dev/sdb1.

This would be a fat change in libisofs. But if
it helps to avoid said problem, i am willing to
implement this.
(We should thoroughly check for other obstacles
 first.)

The change is not necessarily bound to built-in
MBR generation. I assume that an external
isohybrid tool would work too.


Have a nice day :)

Thomas