Re: Replacing the legacy "map" command

[Javier Martín]

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.

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
bootloader.

Anyways, the "drivemap" module is just above the phase of a working
"hello world" - I'm happy! ^.^

Habbit

El jue, 29-05-2008 a las 20:55 -0400, Pavel Roskin escribió:
> On Wed, 2008-05-28 at 16:24 +0200, Robert Millan wrote:
> > On Tue, May 27, 2008 at 11:59:22AM -0400, Pavel Roskin wrote:
> > > 
> > > Again, I'd like to see the command name shortened, perhaps to "drivemap"
> > > or "map".  It's not like users will need to distinguish BIOS and
> > > non-BIOS mappings.
> > 
> > But then we're occupping generic namespace with arch-specific features.
> 
> I think it's OK.  If another architecture supports similar
> functionality, then "drivemap" would still be fine, even if the
> implementation is different.  If an architecture doesn't support it, the
> command won't exist.
> 
> It's very unlikely that there will be two different mechanisms for drive
> remapping, each of which should be available to the users.  And even
> then, a switch could be added to force the preferred mechanism.
>

signature.asc
Description: Esta parte del mensaje está firmada digitalmente