[Top][All Lists]

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

Re: Replacing the legacy "map" command

From: Javier Martín
Subject: Re: Replacing the legacy "map" command
Date: Fri, 30 May 2008 04:13:07 +0200

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

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


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.

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

reply via email to

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