From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1a2xqD-0002xv-G2 for mharc-grub-devel@gnu.org; Sun, 29 Nov 2015 04:00:17 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2xqB-0002xp-29 for grub-devel@gnu.org; Sun, 29 Nov 2015 04:00:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2xq6-0003fr-1g for grub-devel@gnu.org; Sun, 29 Nov 2015 04:00:14 -0500 Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]:36594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2xq5-0003fh-NO for grub-devel@gnu.org; Sun, 29 Nov 2015 04:00:09 -0500 Received: by lfs39 with SMTP id 39so163264796lfs.3 for ; Sun, 29 Nov 2015 01:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=34ePAwRWZ8HnA36C8Y3yl4UX92jzgWnJndUyk7k9HWI=; b=qSLEBfMeUTdwPCL5i3tPpjp8LtH07J650gz/hJHBJK+L/ttgP96ioiYbrhd8RWda6i ZTe6jLRZFglpD9tHUY/jGORhQkeKTqYxZmBTDJ1XNQA2H9Iy2+iOgOKKORaFnSmtmhz/ Rh9j6ig0+EEAgFUU1NZsO55QcUswu88irIwLbp94iVJw/YGBBKeVD8m8nIorCugAq/PW zceMMdf1/+t6UM7Sn/adEOBQORw/wtNrM1CCx5bYV3XR6TEQaq1VtUW7+fUp8iOqhf1g to1rJsjGJ22UvffhFuT3K0/eER/I19DklnwKD1+kdbn/4d/HKRsk/SVMZEPskmudeDyb ZGzQ== X-Received: by 10.25.24.193 with SMTP id 62mr23914729lfy.84.1448787608895; Sun, 29 Nov 2015 01:00:08 -0800 (PST) Received: from [192.168.1.41] (ppp91-76-25-247.pppoe.mtu-net.ru. [91.76.25.247]) by smtp.gmail.com with ESMTPSA id of8sm4129202lbb.7.2015.11.29.01.00.08 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 01:00:08 -0800 (PST) Subject: Re: Grub get and set efi variables To: grub-devel@gnu.org References: <563999B9.7020108@gmail.com> <5643845E.9060204@gmail.com> <5646B275.5040707@gmail.com> <56586384.1030504@gmail.com> From: Andrei Borzenkov Message-ID: <565ABE97.5060109@gmail.com> Date: Sun, 29 Nov 2015 12:00:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c07::234 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 09:00:16 -0000 27.11.2015 17:25, Ignat Korchagin пишет: >> I would add: >> * hex. To print and store in hex form >> * utf16. Decode utf16 into utf8. utf16 is a common encoding in EFI land. > > hex is already part of the latest proposed patch: >>> + case EFI_VAR_HEX: > > I'm not sure whether utf16 will be useful, as all standard UEFI > variables now are using ASCII for string data. > I agree; it can be added later if use case emerges. So far all "interesting" cases that use UTF-16 are not limited to strings, and need much more elaborate parsing. That is why I mentioned generic format specifier before. But this also can be added if needed, overall syntax seems to be flexible enough. > On Fri, Nov 27, 2015 at 2:07 PM, Vladimir 'φ-coder/phcoder' Serbinenko > wrote: >> On 14.11.2015 05:03, Andrei Borzenkov wrote: >>> 13.11.2015 22:42, Ignat Korchagin пишет: >>>>>>> +static enum efi_var_type >>>>>>> +parse_efi_var_type (const char *type) >>>>>>> +{ >>>>>>> + if (!grub_strncmp (type, "string", sizeof("string"))) >>>>>>> + return EFI_VAR_STRING; >>>>>>> + >>>>>> >>>>>> >>>>>> I think this should be "ascii" or "utf8". "string" is too ambiguous >>>>>> in UEFI >>>>>> environment, it can also mean sequence of UCS-2 characters. >>>>> I'm still not sure how exactly GRUB + UEFI interprets "raw buffers" >>>>> when printing. Maybe, to avoid confusion, it might be better to >>>>> completely remove this option. Basically, you do not want to interpret >>>>> raw buffers as strings. For best compatibility "hex" mode should be >>>>> promoted, I guess. What do you think? >>>> Checked again the UEFI spec. For globally defined variables which are >>>> strings they specify ASCII. So if we leave this option, ascii is the >>>> best name. >>>> >>> >>> What about >>> >>> - ascii - print ASCII characters verbatim, escape non-ASCII in usual >>> way (similar to "od -c") >>> >>> - raw - simply put raw variable without any interpretation. >>> >> I would add: >> * hex. To print and store in hex form >> * utf16. Decode utf16 into utf8. utf16 is a common encoding in EFI land. >> I would also skip on raw, at least until we have a real need for it as >> we currently are not equiped to handle raw strings in variable contents, >> including but not limited to \0 being considered a terminator >>> This is better aligned with argument describing output formatting rather >>> than attempting to "type" variable. >>> >>> Alternative (or in addition to) ascii - dump which prints usual pretty >>> hex dump of content (hexdump -C). This is handy to interactively look at >>> variable content. >>> >>> Or, and change name from --type to --format :) >>> >>> _______________________________________________ >>> Grub-devel mailing list >>> Grub-devel@gnu.org >>> https://lists.gnu.org/mailman/listinfo/grub-devel >> >> >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel >> > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >