On 10.11.2015 08:01, Andrei Borzenkov wrote: > Not really, although this is a good observation. Actually I think that > xen_initrd should indeed have behavior 1, because what it does is > provide initrd image to Linux kernel, and - although not often used - > initrd image may be constructed by concatenation. > > But what I meant - initially it was intended to have xen_module with > some options. As soon as we add option parsing we must have defined > way to differentiate between opption for xen_module itself and option > for module loaded by xen_module. I.e. it should be possible to > > xen_module --type=XXX some-module --option1=FOO --option2=bar Yes, everything before the filename would be an option to command itself. We have a similar thing with multiboot command. Currently there are no options to xen_*, so no code to handle them. But it's impossible to get any confusion as if you currently specify any of such future options you'll get an error of bad file, so we won't break any compatibility. Do you see any reason to introduce flag-handling code now? Would it be for better error message?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
