[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] register dummy drive
From: |
Pavel Roskin |
Subject: |
Re: [PATCH] register dummy drive |
Date: |
Wed, 04 Jun 2008 12:41:14 -0400 |
On Wed, 2008-06-04 at 14:07 +0200, Robert Millan wrote:
> On Tue, Jun 03, 2008 at 06:03:51PM -0400, Pavel Roskin wrote:
> > > > >
> > > > > This patch solves the problem by spliting device/drive map[] entry
> > > > > registration
> > > > > into a separate function, and using that from grub-probe.c to
> > > > > register a dummy
> > > > > drive that will last during the current execution.
> > >
> > > Part of what makes grub-probe interesting is that it shares a lot of code
> > > with
> > > the freestanding GRUB you will run later, so when it is used during
> > > grub-install & update-grub, it is very useful to catch possible problems.
> > > I
> > > think hostfs would defeat that purpose.
> >
> > Well, then we probably don't want to ignore any errors. When do you
> > have the situation that the drive cannot be resolved?
>
> For example, when the next version of Linux decides to rename all devices (it
> tends to do that often) and suddenly none of them match any device.map entry.
>
> The thing is, for what we're trying to do (-t fs, -t fs_uuid, -t partmap) we
> don't care how will GRUB identify those devices when it's running on the BIOS,
> so just any string that uniquely identifies them will be enough so we can
> run our filesystem / partmap probes.
OK, then the "dummy drive" is not really dummy. Those in device.map are
dummy :-)
I'm basically fine with anything that gets rid on device.map at least
for single-drive installs.
--
Regards,
Pavel Roskin
Re: [PATCH] register dummy drive, Robert Millan, 2008/06/02