All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: retiring device.map
Date: Fri, 9 May 2008 14:51:44 +0200	[thread overview]
Message-ID: <20080509125144.GB3705@thorin> (raw)
In-Reply-To: <ca0f59980805071039oe1c098ao9048ec39e1e22e19@mail.gmail.com>

On Thu, May 08, 2008 at 01:39:47AM +0800, Bean wrote:
> 
> Yes, UUID can be useful, it's better to add it to grub2.
> 
> UUID itself is quite easy to get, but the question is how to integrate
> it with the existing disk layer. I'm thinking of the following three
> implementation:
> 
> 1, Add a function pointer to fs structure to retrieve UUID, just like label.
> 2. Add a data pointer to the disk structure, the fs driver allocated
> memory when it found UUID.
> 3. Use a separate module to handle UUID. fs driver that found UUID can
> add disk to uuid mapping using exported service.
> 
> Would someone comment on the ideas ?

I'm not completely filled on the basics of UUID.  The location of this
information is defined by the filesystem implementation, right?

In that case, I'd suggest a function to fetch it from grub_fs rather than
a location where it's always copied to.  This allows filesystems that don't
implement it to leave a NULL in it, and doesn't force GRUB to process it
every time (saving time when loading filesystems where UUID isn't going to
be used).

Then search.mod could simply do:

  if (fs->get_uuid)
    my_uuid = fs->get_uuid ();

would that be enough?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)



      parent reply	other threads:[~2008-05-09 12:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4807AA02.1020909@mail.berlios.de>
     [not found] ` <20080418132858.GH29226@thorin>
2008-04-19 14:34   ` grub-probe fails during grub2 update (Debian) Stefan Weil
2008-04-20 10:07     ` Robert Millan
2008-04-21 10:31       ` Pavel Roskin
2008-05-06 15:18         ` retiring device.map Robert Millan
2008-05-06 15:43           ` Pavel Roskin
2008-05-07 13:03             ` Robert Millan
2008-05-07 17:22               ` Pavel Roskin
2008-05-07 17:39                 ` Bean
2008-05-08 17:08                   ` Colin D Bennett
2008-05-09 12:51                   ` Robert Millan [this message]

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=20080509125144.GB3705@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.org \
    /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.