From: Alex Williamson <alex.williamson@hp.com>
To: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com>
Cc: akpm@osdl.org, linux-ia64 <linux-ia64@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Matt_Domsch@dell.com
Subject: RE: [patch 1/3] efivars driver update and move
Date: Thu, 29 Apr 2004 19:50:54 +0000 [thread overview]
Message-ID: <1083268253.8416.100.camel@localhost> (raw)
In-Reply-To: <D36CE1FCEFD3524B81CA12C6FE5BCAB002FFEAB3@fmsmsx406.fm.intel.com>
Good work on the sysfs port, I like it too. I ran into a little
problem trying it with the newest efibootmgr (test3) on an HP rx2600.
I'm not sure what the problem is, so this is a bug report/query.
Efibootmgr complains "show_boot_order(): No such file or directory".
However, it looks ok:
# find /sys/firmware/efi/vars/ -name BootOrder*
/sys/firmware/efi/vars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
Looking at the directory a little more closely
# stat BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c\ /
File: `BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c /'
...
What's the purpose of the ' ' at the end of the directory name? The
comment in the code suggests it might have a purpose:
/* This is ugly, but necessary to separate one vendor's
private variables from another's. */
*(short_name + strlen(short_name)) = '-';
efi_guid_unparse(vendor_guid, short_name + strlen(short_name));
*(short_name + strlen(short_name)) = ' ';
But the same comment was in the /proc efivar code, without the
additional space tagged onto the end. All of the EFI variables end with
a space, so there's nothing special about this one. Is the space
intentional? The data in the variable looks good otherwise:
# xxd BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c\ /data
0000000: 0100 0000 0200 0500 0600 0300 ............
# xxd BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c\ /guid
0000000: 3862 6534 6466 3631 2d39 3363 612d 3131 8be4df61-93ca-11
0000010: 6432 2d61 6130 642d 3030 6530 3938 3033 d2-aa0d-00e09803
0000020: 3262 3863 0a 2b8c.
# xxd BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c\ /attributes
0000000: 4546 495f 5641 5249 4142 4c45 5f4e 4f4e EFI_VARIABLE_NON
0000010: 5f56 4f4c 4154 494c 450a 4546 495f 5641 _VOLATILE.EFI_VA
0000020: 5249 4142 4c45 5f42 4f4f 5453 4552 5649 RIABLE_BOOTSERVI
0000030: 4345 5f41 4343 4553 530a 4546 495f 5641 CE_ACCESS.EFI_VA
0000040: 5249 4142 4c45 5f52 554e 5449 4d45 5f41 RIABLE_RUNTIME_A
0000050: 4343 4553 530a CCESS.
# xxd BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c\ /size
0000000: 3078 630a 0xc.
Thanks,
Alex
--
Alex Williamson HP Linux & Open Source Lab
WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@hp.com>
To: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com>
Cc: akpm@osdl.org, linux-ia64 <linux-ia64@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Matt_Domsch@dell.com
Subject: RE: [patch 1/3] efivars driver update and move
Date: Thu, 29 Apr 2004 13:50:54 -0600 [thread overview]
Message-ID: <1083268253.8416.100.camel@localhost> (raw)
In-Reply-To: <D36CE1FCEFD3524B81CA12C6FE5BCAB002FFEAB3@fmsmsx406.fm.intel.com>
Good work on the sysfs port, I like it too. I ran into a little
problem trying it with the newest efibootmgr (test3) on an HP rx2600.
I'm not sure what the problem is, so this is a bug report/query.
Efibootmgr complains "show_boot_order(): No such file or directory".
However, it looks ok:
# find /sys/firmware/efi/vars/ -name BootOrder*
/sys/firmware/efi/vars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
Looking at the directory a little more closely
# stat BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c\ /
File: `BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c /'
...
What's the purpose of the ' ' at the end of the directory name? The
comment in the code suggests it might have a purpose:
/* This is ugly, but necessary to separate one vendor's
private variables from another's. */
*(short_name + strlen(short_name)) = '-';
efi_guid_unparse(vendor_guid, short_name + strlen(short_name));
*(short_name + strlen(short_name)) = ' ';
But the same comment was in the /proc efivar code, without the
additional space tagged onto the end. All of the EFI variables end with
a space, so there's nothing special about this one. Is the space
intentional? The data in the variable looks good otherwise:
# xxd BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c\ /data
0000000: 0100 0000 0200 0500 0600 0300 ............
# xxd BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c\ /guid
0000000: 3862 6534 6466 3631 2d39 3363 612d 3131 8be4df61-93ca-11
0000010: 6432 2d61 6130 642d 3030 6530 3938 3033 d2-aa0d-00e09803
0000020: 3262 3863 0a 2b8c.
# xxd BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c\ /attributes
0000000: 4546 495f 5641 5249 4142 4c45 5f4e 4f4e EFI_VARIABLE_NON
0000010: 5f56 4f4c 4154 494c 450a 4546 495f 5641 _VOLATILE.EFI_VA
0000020: 5249 4142 4c45 5f42 4f4f 5453 4552 5649 RIABLE_BOOTSERVI
0000030: 4345 5f41 4343 4553 530a 4546 495f 5641 CE_ACCESS.EFI_VA
0000040: 5249 4142 4c45 5f52 554e 5449 4d45 5f41 RIABLE_RUNTIME_A
0000050: 4343 4553 530a CCESS.
# xxd BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c\ /size
0000000: 3078 630a 0xc.
Thanks,
Alex
--
Alex Williamson HP Linux & Open Source Lab
next prev parent reply other threads:[~2004-04-29 19:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-22 15:51 [patch 1/3] efivars driver update and move Matt Tolentino
2004-04-22 17:32 ` Matt Tolentino
2004-04-22 16:46 ` Bjorn Helgaas
2004-04-22 16:46 ` Bjorn Helgaas
2004-04-22 17:14 ` Tolentino, Matthew E
2004-04-22 17:14 ` Tolentino, Matthew E
2004-04-22 17:20 ` Bjorn Helgaas
2004-04-22 17:20 ` Bjorn Helgaas
2004-04-29 19:50 ` Alex Williamson [this message]
2004-04-29 19:50 ` Alex Williamson
2004-04-29 21:19 ` Matt Domsch
2004-04-29 21:19 ` Matt Domsch
2004-04-29 22:08 ` Alex Williamson
2004-04-29 22:08 ` Alex Williamson
2004-04-23 22:29 ` Matt Domsch
2004-04-23 22:29 ` Matt Domsch
2004-04-24 3:41 ` Matt Domsch
2004-04-24 3:41 ` Matt Domsch
2004-04-26 18:57 ` Matt Domsch
2004-04-26 18:57 ` Matt Domsch
2004-04-26 19:30 ` Matt Tolentino
2004-04-26 21:15 ` Matt Tolentino
2004-04-30 0:09 ` Matt Tolentino
2004-04-30 1:55 ` Matt Tolentino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1083268253.8416.100.camel@localhost \
--to=alex.williamson@hp.com \
--cc=Matt_Domsch@dell.com \
--cc=akpm@osdl.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.e.tolentino@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.