Re: [PATCH 4/4] Allow protocol to be separated from host with a semicolon

[Andrei Borzenkov <arvidjaar@gmail.com>]

On Wed, Jan 25, 2017 at 10:16 AM, Matthew Garrett <mjg59@coreos.com> wrote:
> On Tue, Jan 24, 2017 at 10:56 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>> On Wed, Jan 25, 2017 at 7:25 AM, Matthew Garrett <mjg59@coreos.com> wrote:
>>> If prefix isn't set then won't bootfile be interpreted as the device plus file?
>>>
>>
>> No. That would mean "parsing URI" that I mentioned.
>
> My experience is that configfile (http,example.com)grub/config works
> as you'd expect it to, and that set
> endpoint=$net_efinet0_dhcp_boot_file; configfile $endpoint does the
> same. Am I hitting some corner case where things are being incorrectly
> parsed and so giving me unintended functionality?
>

When grub starts it tries to determine device and path it was booted
from. For network boot it currently means examining DHCP ACK packet
that is normally provided by firmware and setting device to
tftp,$next_ip and path to $bootfile. There is no provision to set
protocol to anything else nor to parse $bootfile to extract
protocol/server.

If you speak about "configfile something" you are past this point so
DHCP $bootfile option is not relevant at all.

>>> We need the ability to pass port as well, so that would still be insufficient.
>>
>> Good. So start with design proposal that is extensible enough.
>>
>> But TBH - all of this can already be implemented using grub scripting.
>> Use custom DHCP options or parse bootfile using regex. No code changes
>> is needed - we support generic scripting for a reason.
>
> How are custom DHCP options handled? I can't find anything in the
> documentation about them being interpreted, and a quick look at the
> code only shows it setting known variables.

You have net_get_dhcp_option to fetch arbitrary option value from DHCP
ACK packet and put it in variable for further processing. I'm
definitely open to improving this command to make it more useful if it
turns out lacking something.