On Wednesday, November 27, 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 27.11.2013 19:57, Andrey Borzenkov wrote: > > В Wed, 27 Nov 2013 13:44:41 -0500 > > SevenBits <sevenbitst...@gmail.com <javascript:;>> пишет: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > > > >> On 11/25/2013 07:22 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > >>> On 25.11.2013 23:28, SevenBits wrote: > >>>> > >>>> On 11/25/2013 05:07 PM, Vladimir '?-coder/phcoder' Serbinenko > >>>> wrote: > >>>>> On 25.11.2013 23:03, SevenBits wrote: > >>>>>> > >>>>>> Thanks for your quick reply. > >>>>>> > >>>>>> I just have a couple of questions. How do you prefer I allow > >>>>>> the user to specify the vendor UUID? By typing it in via the > >>>>>> keyboard? And secondly, by saying it needs "readable aliases > >>>>>> for known types" do you mean that there should be a function > >>>>>> to set an integer, one to set a boolean, etc? > >>>>>> > >>>>> I meant for UUIDs. E.g. one alias "efi" for shared space, > >>>>> "apple" for apple and so on. > >>>> So other than a generic variable UUID and Apple, are there others > >>>> that you think might be necessary? I can try and put in some > >>>> common ones but manufacturers may not disclose what their > >>>> specific UUIDs are. > >>>> > >>> I'd include a command to list variables (interactively). We would > >>> pretty quickly collect most common UUIDs this way. > > > >> So, I've got a command written to print out the system's firmware > >> variables. Trouble is I'm not sure what the best way would be to print > >> or otherwise display the UUIDs gathered so that we can collect them. > > > > > > I think it is rather premature at this point. > Agreed. I wasn't clear enough that I meant that in the first > implementation we need to put just few UUIDs we already know about as > aliases and expand them with the time. Okay, sounds okay to me. I'll be occupied because of the holidays here in the United States but I can get on it as soon as I can. > > What is needed first is > > sane framework for handling EFI variables, which means - handling GUID, > > options (during set or as filter in listing variables) and conversion of > > arbitrary binary data from/to external printable representation. I think I get what you mean. I'll focus on this area then. > > > > > >>>>> But type of variable is also an issue and there should be at > >>>>> least following available: hex - transform all in hex utf16 - > >>>>> decode utf16 into utf8 Probably more, didn't really look into > >>>>> issue > >>>> I see, okay, I'll add some in. > >>>> > > > > > > Yes, please. Adding aliases for GUID can always come later and is not > > really that important. Alright. Any specific ideas of where I should put the code? In with the other UEFI handling stuff or in the code for the module I'm writing? > > _______________________________________________ > > Grub-devel mailing list > > Grub-devel@gnu.org <javascript:;> > > https://lists.gnu.org/mailman/listinfo/grub-devel > > > > >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
