Date: Mon, 9 Mar 1998 11:34:27 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Ned Ulbricht <nedu AT ee DOT washington DOT edu>
cc: djgpp AT delorie DOT com
Subject: Re: hdparm lets your IDE disk spin down
In-Reply-To: <199803090138.RAA12095@mailhost2.cac.washington.edu>
Message-ID: <Pine.SUN.3.91.980309113407.22925M-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Sun, 8 Mar 1998, Ned Ulbricht wrote:

> But the system itself is able to resolve this 
> problem, right?  The reference I checked says that this is DOS's 
> first step.

AFAIK, DOS doesn't have to solve this problem.  It is the job of the
block device driver.

> And the DPB does get you past subst'd and assign'd drives 
> which is something that's absolutely needed. (You could look at the 
> CDS instead, but why?).

To resolve JOIN and SUBST, just use the `_truename' library function.
Even `stat' will correctly report the drive in the st_dev member of
struct stat (it calls `_truename' internally).

> >      - How do you know what is the number of the zeroth unit number
> >        (usually 80h for C:, but how do you know it)?
> 
> When isn't that true?

When C: isn't a local hard disk, for starters.  DOS allocates the
drive letters in the order it sees the block devices when it boots.  A
clever device driver loaded early from CONFIG.SYS could fool DOS into
anything it likes.

> Anyhow, turn & turn about's fair play.  You suggested reading the 
> disk--how does that get you there?

I don't have a complete solution either.  I thought you did (or so
your message implied).  I thought about this a bit some time ago when
I wrote the `_flush_disk_cache' function for the DJGPP library.  I
wanted it to work by resetting the controller for the right disk, so I
wanted to know the mapping between physical and logical drives.  I
dumped the idea after I quickly saw it doesn't have an easy solution.
(The current version of `_flush_disk_cache' assumes that the BIOS Disk
Reset function on any drive flushes the cache, which seems to work.)

If somebody *really* needs to find the mapping, they could begin by
calling Int 13h/AH=08 for drives 080h and 081h (and maybe for a couple
more, just to be sure) and record the number of disks attached to each
controller which is returned in the DL register.  Then you'd need to
figure out how the disks are partitioned into logical drives.  For
that, you will need to read the partition table, figure out which of
the entries are active, and build the mapping assuming that the drive
letters are assigned in the order you see the active partitions,
beginning with C:.  This is gross, of course, and isn't 100%
bullet-proof, either.