From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1cWI8o-0003in-6A for mharc-grub-devel@gnu.org; Wed, 25 Jan 2017 02:37:14 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cWI8l-0003hR-Gt for grub-devel@gnu.org; Wed, 25 Jan 2017 02:37:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cWI8k-0000QU-OG for grub-devel@gnu.org; Wed, 25 Jan 2017 02:37:11 -0500 Received: from mail-qk0-x242.google.com ([2607:f8b0:400d:c09::242]:33157) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cWI8k-0000QM-J5 for grub-devel@gnu.org; Wed, 25 Jan 2017 02:37:10 -0500 Received: by mail-qk0-x242.google.com with SMTP id 11so9396277qkl.0 for ; Tue, 24 Jan 2017 23:37:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JEa0nM5iBw2o28eTpHvN4JMoHfuF1Wtp+xFtLIcuowI=; b=SX0TEt4yAtn0GN93TaDio9JHSuPD8RLTA38VEOXbAeys8qw0GNDg1NbtRzEONAILUr yBqC1MWJpipLRC9Y6ewav1FvunjaJof07uq+OZjXr+5M//OQUc1BvP4PR0C16xnbUAAt FQJKATGCYlTqVB3e0hpr82U4WyyIiUeiboP+AYaTzIQYibffKcpgdZ1VDqScVnF2511k yR/OoKpy1dTSOyCMPT+uQIbwelY3/Dh7fZXgj3n5/MKo7CBYazEf0HuC7Gp4NWK0COwx KGRQcMKGd+7mrTzHxlDxb92ZD8l+pnafsMD5RRO6OthtOAWGVq7Q8WqAGbv7SXiH464l hfTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JEa0nM5iBw2o28eTpHvN4JMoHfuF1Wtp+xFtLIcuowI=; b=qr/i1mhTtzoqBMmshyq1P2rhff4dDATTYM+yBAJT2c8DZG/rze42n2wE82K5neGBUs wZvI+9brdJ63FmFSUHEpNH5IBBzNchhqSo2d80CNkzwEZ3aGcLQWsOunsfKTu7qfr9fP am2/Eqr4A5bWA2MZEVCtlHHSxSm/+jFYavgh9Ce+ZZzEXr0Hlyh0FU1yuyMMiqhE7dlD TIunU/80JtT5yRL+Pmyo6IN6mN5L8K7HO0aptx+PTdz32AmtRJiba5tPM4Hc0FiM33Xz ntMfDOaln45+t7zGhMOsYgXMM05GnRbJwOXHrMf4H9Cqnfi3TTikG6jFaNFOH/SlFgXt v3Ig== X-Gm-Message-State: AIkVDXJSDlMCFB2xvUM8Ulrz5Kc+0a1nMOtugyYrrQ8l1Xyeh3wV3nKkFp6/5AwObAVgy4PGD30EfO/Yzh4S+w== X-Received: by 10.55.18.76 with SMTP id c73mr32560604qkh.119.1485329830022; Tue, 24 Jan 2017 23:37:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.41.245 with HTTP; Tue, 24 Jan 2017 23:37:09 -0800 (PST) In-Reply-To: References: <20170124003601.24612-1-mjg59@coreos.com> <20170124003601.24612-5-mjg59@coreos.com> <411c7ef8-85a2-afd8-7446-0fd8d3d98616@gmail.com> From: Andrei Borzenkov Date: Wed, 25 Jan 2017 10:37:09 +0300 Message-ID: Subject: Re: [PATCH 4/4] Allow protocol to be separated from host with a semicolon To: Matthew Garrett Cc: The development of GNU GRUB Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c09::242 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 07:37:12 -0000 On Wed, Jan 25, 2017 at 10:16 AM, Matthew Garrett wrote: > On Tue, Jan 24, 2017 at 10:56 PM, Andrei Borzenkov wrote: >> On Wed, Jan 25, 2017 at 7:25 AM, Matthew Garrett 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.