grub-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]