Hi. Are we still considering this?
On Mon, Dec 14, 2015 at 11:17 AM, Ignat Korchagin
wrote:
> Sorry, pasted wrong file. Here is the correct one:
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 0cc40bb..aa7b927 100644
> --- a/grub-core/Makefile.core.def
> +++ b/
Sorry, pasted wrong file. Here is the correct one:
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 0cc40bb..aa7b927 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -735,6 +735,12 @@ module = {
};
module = {
+ name = efivar;
+ efi = co
> Assuming uint8 remains - should not you check that variable size is exactly 1
> byte in this case?
There are reports of a buggy firmware returning 4 bytes size for uint8
variables, however did not encounter them myself.
> Do we really need unit8 at all? "hex" already provides exactly the same
03.12.2015 20:19, Ignat Korchagin пишет:
>> This should be grub_strcmp everywhere, there is no reason to use
>> grub_strncmp.
> Yes, you are right. Please, find updated patch below
>
>> I believe it should be "content" (without final `s') but English is not
>> native
> Mine not as well, but aske
Is this still considered?
On Thu, Dec 3, 2015 at 5:19 PM, Ignat Korchagin wrote:
>> This should be grub_strcmp everywhere, there is no reason to use
>> grub_strncmp.
> Yes, you are right. Please, find updated patch below
>
>> I believe it should be "content" (without final `s') but English is no
> This should be grub_strcmp everywhere, there is no reason to use grub_strncmp.
Yes, you are right. Please, find updated patch below
> I believe it should be "content" (without final `s') but English is not native
Mine not as well, but asked my native colleagues and they confirmed
"contents". Als
02.12.2015 17:52, Ignat Korchagin пишет:
> OK. Updated patch below:
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 0cc40bb..aa7b927 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -735,6 +735,12 @@ module = {
> };
>
> modul
OK. Updated patch below:
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 0cc40bb..aa7b927 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -735,6 +735,12 @@ module = {
};
module = {
+ name = efivar;
+ efi = commands/efi/efivar.c;
+ en
Le 2 déc. 2015 2:01 PM, "Andrei Borzenkov" a écrit :
>
> On Wed, Dec 2, 2015 at 3:53 PM, Ignat Korchagin
wrote:
> > Let's add utf16 later then (if needed). I also noticed a typo in one
> > error string in my above patch (it was checking that command receives
> > one argument, but prints that
On Wed, Dec 2, 2015 at 3:53 PM, Ignat Korchagin wrote:
> Let's add utf16 later then (if needed). I also noticed a typo in one
> error string in my above patch (it was checking that command receives
> one argument, but prints that two arguments expected), so here is the
> updated one.
>
It is much
Let's add utf16 later then (if needed). I also noticed a typo in one
error string in my above patch (it was checking that command receives
one argument, but prints that two arguments expected), so here is the
updated one.
So, finally, should I remove the "raw" parser (as per Vladimir's
request). P
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 use
17.11.2015 14:48, Ignat Korchagin пишет:
> Please, see updated patch below. I tried to reuse GRUB hexdump
> function, so as a result dump will not work with setting vatiables -
> just dumping to stdout. But it doesn't make sense to assign dump to a
> variable anyway.
>
> diff --git a/grub-core/com
> 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 ASC
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 thi
That sounds like a firmware implementation bug, unfortunately. I've seen it be
hit or miss setting boot service only variables on some platforms.
--S
> On Nov 24, 2015, at 11:23 AM, Mat Troi wrote:
>
> For a specific project implementation, I need to be able to write and read
> one EFI
For a specific project implementation, I need to be able to write and read
one EFI variable during boot only. So I have written a grub command to do
just that. But the issue is with setting these attributes to the variable
(GRUB_EFI_VARIABLE_NON_VOLATILE, GRUB_EFI_VARIABLE_BOOTSERVICE_ACCESS), I
Please, see updated patch below. I tried to reuse GRUB hexdump
function, so as a result dump will not work with setting vatiables -
just dumping to stdout. But it doesn't make sense to assign dump to a
variable anyway.
diff --git a/grub-core/commands/efi/efivar.c b/grub-core/commands/efi/efivar.c
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 al
On Fri, Nov 13, 2015 at 11:34 AM, Ignat Korchagin wrote:
> On Wed, Nov 11, 2015 at 10:09 AM, Andrei Borzenkov
> wrote:
>> 06.11.2015 05:00, Ignat Korchagin пишет:
>>>
>>> Actually, I submitted similar patch recently as well. It provides read
>>> function for variables and accepts a hint on how t
On Wed, Nov 11, 2015 at 10:09 AM, Andrei Borzenkov wrote:
> 06.11.2015 05:00, Ignat Korchagin пишет:
>>
>> Actually, I submitted similar patch recently as well. It provides read
>> function for variables and accepts a hint on how to process them. The
>> original patch is here:
>> https://lists.gnu
06.11.2015 05:00, Ignat Korchagin пишет:
Actually, I submitted similar patch recently as well. It provides read
function for variables and accepts a hint on how to process them. The
original patch is here:
https://lists.gnu.org/archive/html/grub-devel/2015-09/msg00043.html.
Yes, I was intendin
Actually, I submitted similar patch recently as well. It provides read
function for variables and accepts a hint on how to process them. The
original patch is here:
https://lists.gnu.org/archive/html/grub-devel/2015-09/msg00043.html.
Probably, I forgot to enable plain-text mode, so it got there as
On Wednesday, November 4, 2015, Andrei Borzenkov
wrote:
> 04.11.2015 02:05, Mat Troi пишет:
>
>> Hi SevenBits,
>>
>> Thanks for letting me know. Out of curiosity, any particular reason why
>> this patch did not get merged? It looks to be a useful feature.
>>
>>
> First, this patch was reverse p
04.11.2015 02:05, Mat Troi пишет:
Hi SevenBits,
Thanks for letting me know. Out of curiosity, any particular reason why
this patch did not get merged? It looks to be a useful feature.
First, this patch was reverse patch :)
I am not convinced making it easy to set EFI variable from within G
Hi SevenBits,
Thanks for letting me know. Out of curiosity, any particular reason why
this patch did not get merged? It looks to be a useful feature.
Thanks,
Mat
On Tue, Nov 3, 2015 at 12:12 PM, SevenBits wrote:
> On Tuesday, November 3, 2015, Mat Troi wrote:
>
>> Hi,
>>
>> Searching throug
On Tuesday, November 3, 2015, Mat Troi wrote:
> Hi,
>
> Searching through google, I see there was an email thread to add a patch
> for getting and setting efi variable in GRUB2.
> https://lists.gnu.org/archive/html/grub-devel/2013-11/msg00328.html
>
> However, looking at the tree, it doesn't look
Hi,
Searching through google, I see there was an email thread to add a patch
for getting and setting efi variable in GRUB2.
https://lists.gnu.org/archive/html/grub-devel/2013-11/msg00328.html
However, looking at the tree, it doesn't look like this patch was added, am
I missing something? Does an
28 matches
Mail list logo
