All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.