[syslinux] [PATCH] ifmemdsk.c32: Allow boot options based on presence of MEMDISK

[Shao Miller]

On 8/8/2011 14:02, Bernd Blaauw wrote:
> Op 8-8-2011 19:33, Shao Miller schreef:
>> I don't follow. For the 'memdisk iso' scenario, INT 0x13, AH==0x08
>> MEMDISK probe isn't going to work, as only the AH==0x4X functions
>> work... So I would agree that one or both of '--mbfts' and
>> '--safe-hooks' must be used in order to detect the MEMDISK. Nothing will
>> "show" without '--info'.
>
> As memdisk/ifmemdsk.c32 can detect it's currently being booted by 
> Isolinux these options could be implicit instead of a 'nothing 
> specified, nothing done'.

Besides both being part of the Syslinux suite of software and primarily 
coded by hpa, what does ISOLINUX have to do with MEMDISK?  It seems 
unnatural to me for 'ifmemdsk.c32' to be concerned with the particular 
Syslinux variant currently owning the computer; the command detects 
MEMDISKs, not Syslinuces.  Since an established MEMDISK might or might 
not have anything to do with the currently-running Syslinux, why add 
special-case behaviour that deviates from DOS' mdiskchk.com?

As a contrived example, one could do: PXELINUX -> MEMDISK + GRUB4DOS 
floppy -> iPXE -> sanboot an .ISO with ISOLINUX.  Should 'ifmemdsk.c32' 
running under that ISOLINUX automatically use '--mbfts' or 
'--safe-hooks'?  I don't think so.  But if so, which of those two 
options should it choose?  The MEMDISK is a little ways up the chain and 
has little to do with the running ISOLINUX.

> my very commandline for testing, inside the inner iso, was a:
> /isolinux/ifmemdsk.c32 yes -- no
> (followed by waiting for 'yes not found' or 'no not found')
>
> as that wasn't a succes I expanded it to:
> /isolinux/ifmemdsk.c32 --mbfts yes -- no
>

Right.  As mentioned, the classic INT 0x13, AH==0x08 probe won't work 
for 'memdisk iso'.

>> So how about a '--find' option?:
>
> sounds good.
>

Great!

>> LABEL test1
>> COM32 ifmemdsk.c32
>> APPEND --mbfts --find test1 echo.c32 Found test1 -- echo.c32 No test1
>> LABEL test2
>> COM32 ifmemdsk.c32
>> APPEND --mbfts --find test2=foo echo.c32 Found test2=foo -- echo.c32 No
>> test2=foo
>>
>> Does that seem sensible? I'll probably wait for some hpa-approval of the
>> current, basic incarnation before attempting a '--find' feature.
>
> I'm confused by your test2 label, but in general it looks good yes.

The '<item>' in the 'test2' label is 'test2=foo', which happens to be 
part of the established MEMDISK's command-line and should result in the 
'echo.c32 Found test2=foo' command being run.

> Ideally I'd stick to a single config file but doubt it's possible as 
> the "IF.." / "KERNEL" modules/keywords can only execute programs and 
> labels, not keywords.
>
> COM32 /isolinux/ifmemdsk.c32 --mbfts fdos -- showmenu
>

I don't completely understand your target scenario (and might've missed 
some relevant e-mail), but maybe that's not important.  Why would an 
"outer" .ISO have the same config-file as an "inner" .ISO?  Suppose you 
have, in the outer .ISO:

   LABEL test4memdisk
     COM32 /isolinux/ifmemdsk.c32 --mbfts load_inner -- show_menu
   LABEL load_inner
     KERNEL memdisk
     INITRD inner.iso
     APPEND iso
   LABEL show_menu
   ...

If no MEMDISK is detected, the 'load_inner' label will run, and MEMDISK 
will be booted...  Control will not return to ISOLINUX.  A _new_ 
ISOLINUX, within 'inner.iso', will be run.  Since that new ISOLINUX has 
a new "root filesystem," its config-file is not the same file as for the 
"outer," above.  So in your 'inner.iso', oughtn't it to know that it's 
guaranteed to be a MEMDISK?

If not (because you sometimes burn this "inner" .ISO to physical media), 
how could it possibly be useful to test whether or not it's running as a 
MEMDISK in order to make a choice about booting another MEMDISK?  If it 
is the "inner" .ISO, then it has no further "inner things" to MEMDISK.

Maybe this isn't your scenario. :)

> I'll stick to whatever works though, hopefully including a MBOOT.C32 
> at some time that is able to set root before chaining :)

Ok.

> Switching to GRUB/Grub4dos/BURG/GRUB2/GRUB24DOS/BURG2 in either 
> uncompressed or compressed versions wasn't my intention :)

You've lost me. :)

- Shao Miller