[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Replacing the legacy "map" command

From: Pavel Roskin
Subject: Re: Replacing the legacy "map" command
Date: Thu, 29 May 2008 23:48:33 -0400
User-agent: Internet Messaging Program (IMP) H3 (4.1.4)

Quoting Javier Martín <address@hidden>:

Then "drivemap" it is. I've already been delving into the depths of The
Source, though I'd have preferred it to be commented a bit more
exhaustively. Some times it's difficult to guess which methods to call,
and it took me a bit to realize that I had to check with the disk
"device" to see if it was a BIOS drive. Seems I had the wrong conception
of what the disk "device" should be.

I suggest a simple approach starting from what can be done. There will be a small resident piece of code installed to intercept interrupt 0x13 and replace the driver number according to the map. We should keep that code simple.

The resident code should go through the list of the mapped drives, and if there is an entry in the table, replace the drive number. That's two bytes for an entry.

I think the user interface should operate directly on that unidirectional map rather that with some complex swap rules that are translated to the map. Sure, it won't be nice if some device is seen as two devices, especially if the OS uses BIOS. But GRUB cannot prevent all stupid actions by users.

By the way, floppies are usually also "BIOS drives". Should the command
filter them out as sources for mapping? I think so, because OS loaders
usually have different code for reading floppies and HDs. Concretely,
floppy code usually makes some assumptions about drive geometry, uses
only old CHS-like interfaces, and some things more I cannot remember
now... it's been long since I wrote anything distantly similar to a

We may still want to map a hard drive as a floppy. I can imagine that some floppy readers may be seen as hard drives by the BIOS.

I think it's not the most important thing at the moment. If there is a substantial risk of data corruption due to floppy-to-hdd remapping or duplicate drives, we can introduce extra safety checks.

Pavel Roskin

reply via email to

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