Re: [PATCH] register dummy drive

[Robert Millan <rmh@aybabtu.com>]

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.

> My concern is that introducing a dummy object for non-testing purposes
> could indicate bad code quality.

It got a bit stuck anyway; see my other mail about -t partmap not working
with this method.

-- 
Robert Millan

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