[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cannot pass a single backslash in multiboot cmdline

From: Andrei Borzenkov
Subject: Re: Cannot pass a single backslash in multiboot cmdline
Date: Tue, 27 Dec 2016 11:02:19 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

26.12.2016 21:56, Jakub Jermář пишет:
> On 12/26/2016 07:24 PM, Andrei Borzenkov wrote:
>> 26.12.2016 21:12, Jakub Jermář пишет:
>>>>> I am observing a strange behavior when passing boot arguments with a
>>>>> backslash to the kernel (the multiboot cmd_line via the multiboot
>>>>> command in grub.cfg). I would like to pass foo\bar to the kernel, but to
>>>>> no avail. I tried:
>>>> Which kernel? What do you load?
>>> The kernel is a modified version of HelenOS, but IMHO this issue is
>>> kernel agnostic.
>> Not really. It depends on target program being loaded which is why I
>> asked what you use.
> Ok, I submitted my grub.cfg and stated that HelenOS is
> multiboot-compliant, gets loaded by the multiboot command. We boot from
> an ISO image, which was created like this:
> "The binary files of GRUB boot loader in this directory have been
> created by compiling GRUB for the 'i386-pc' target and then using the
> grub-mkrescue script to create the El Torito boot image."
> Is there anything else I should include in order to answer your question?

Multiboot only passes single "string" as command line. As far as I can
tell this is true for both multiboot1 and multiboot2. Loaded kernel
likely will need to parse this string to split it into individual
parameters. This means that to pass character(s) used to split string
verbatim you need some quoting rules.

So it is up to you to define how your kernel parses string. grub is just
the messenger here.

>>> The cmd_line is already wrong when picked up from the
>>> multiboot info and printed out (so there is no processing on it from the
>>> HelenOS side).
>> Sure, but /if/ your kernel interpreted `\' as quoting character, the
>> result would be correct.
> But instead of the plain actual data there would be escaped data, which
> is a hassle. And also a possible workaround.

Again - how your kernel splits string into multiple parameters? Assuming
your kernel does support multiple parameters of course.

>>> I think I understand why it is eating the single backslash (expected
>>> behavior),
>> You have two levels here. First level is grub command line processing.
>> It is loosely compatible with (Bourne) shell so yes, backslash is
>> treated as escape character. You can still pass backslash using usual
>> shell quoting, e.g. foo\\bar or 'foo\bar'. Second level is
>> grub_create_loader_cmdline() function. This one escapes `\' with second
>> `\'. So in the above case this function receives `foo\bar' as adds
>> second `\'.
> This explains a lot, but does not make much sense for my usecase.

Sure but we need to understand your use case first :)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]