> If I understand the syntax correct, it is:
> (hdX,Y)/path/to/file", where X is disk number and Y is partition
number.
> As far as I understand X and Y are zero based.
>
> I've tested it with qemu and 2 disks:
> - the first with bootloader
> - the second with kernel+rootfs
>
> I've used the following configuration file label:
>
> label MULTIFS
> KERNEL (hd1,1)/mfs/bzImage
> APPEND root=/dev/ram0 initrd=(hd1,1)/mfs/rootfs.ext2 ramdisk_size=65536
> quiet
>
1_ At this time, this is yet unfinished (and, strictly speaking, yet
unofficial).
2_ In the "(hdX,Y)" syntax, the "Y" should not be
zero-based, but
rather one-based. The "X" should be zero-based.
3_ We have already agreed (a "long" time ago) that the syntax for
multifs shall follow the syntax of the chain.c32 module (see the wiki).
4_ It is still not completely clear whether or how the multifs syntax
will/should/would be able to support the alternatives that are
currently supported by chain.c32. The alternatives are relevant because
the "X,Y" values are not always known in advance. Some examples:
_ "X Y" (i.e. space character instead of comma, supported by
chain.c32);
_ "label="
_ "guid="
_ "mbr:"
_ "fd#"
5_ It is not completely clear whether or how the multifs syntax
will/should/would be able to support "relative" notations. Some
examples:
_ The path to be searched-for is located in "the *next* disk device
after the current 'boot'" (where 'boot' is to be understood
in the same
way as chain.c32 uses it).
_ The path to be searched-for is located in "the *prior* disk device
before the current 'boot'" (where 'boot' is to be
understood in the
same way as chain.c32 uses it).
_ The path to be searched-for is located in "the *next* partition
device after the current 'boot/fs'" (where 'boot' and/or
'fs' are to be
understood in the same way as chain.c32 uses them).
_ The path to be searched-for is located in "the *prior* partition
device before the current 'boot/fs'" (where 'boot' and/or
'fs' are to
be understood in the same way as chain.c32 uses them).
6_ It is not yet clear whether the multifs feature would eventually
include possibilities (i.e. paths' syntax) similar to the current
pxechn.c32 module, or other types of "some_other_server" or
"paths"
(e.g. "http://...").
7_ It is not completely clear whether there should be some additional
(or different) syntax options for multifs in other scenarios, such as
GPT in BIOS, or for UEFI systems.
8_ The use of curved brackets (aka parentheses) has not been fully
discussed. One advantage of these specific characters is that this pair
is already in use by other bootloader(s), but that does not mean that
they are the best choice (although, they might be).
9_ The use of "hd" in "(hdX,Y)" might or might not be needed
by the
time the multifs feature gets to some official release of Syslinux.
To be clear, I am not saying that any of the aforementioned points are
of high(er) / low(er) priority or that they need to be discussed right
now (and frequent readers of this Syslinux Mailing List might know that
I am more concerned about the current regressions rather than anything
else regarding Syslinux).
Regards,
Ady.
