[Top][All Lists]

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

Re: status grub2 port of grub-legasy map command

From: Javier Martín
Subject: Re: status grub2 port of grub-legasy map command
Date: Sat, 18 Apr 2009 04:18:14 +0200

El vie, 17-04-2009 a las 20:01 -0400, John Stanley escribió:
> Ok, that sounds good... I feel better about it then. I didn't mean 
> directly modifying bios data, but through doc'd bios ints of course. It 
> been a long, long time since I've looked at (or dealt with) bios code, 
> so I was was simply wondering if boot device naming  could be modified  
> in  a  documented way nowadays-- after all, the functionality has been 
> available in the bios setup in pcs for at least 10 years or so.

Indeed. However, this is not necessary as most modern OSes only use the
BIOS routines for the initial startup, switching sooner than later to
their own device drivers. The problem with some of them, among them MS
Windows, is that the loader stage fails to either notice the "boot drive
number" info passed in %dl by the BIOS (or, in this case, by GRUB)
and/or propagate it to latter stages of their multi-stage pre-boot
process. As an example, FreeDOS ignores the parameter and fails to
locate KERNEL.SYS, while ReactOS's freeldr uses it and is able to load
its config file, but then fails to boot the (drive-#-hardcoded) paths in
that same file.

This sorry state of things motivates most BIOSes to actually "swap" your
"designated boot device" with the actual first HD, so that systems that
assume they were installed on hd0 will work. Drivemap basically
replicates this functionality using the "canonical" real-mode interrupt
handler chaining pattern: it intercepts calls to the BIOS drive access
interrupt and calls the previous handler after performing its role. This
is not a "dirty hack" (well, it _is_ by current standards), and in fact
it was the way TSRs worked in DOS. Here's what happens when the Windows
loader (or FreeDOS, etc.) tries to access the drives:

ntldr --(int13h: r,0x80)--> drivemap_int13h --(lcall: f,r,0x81)-->BIOS

Drivemap (and other TSRs) actually _simulate_ an interrupt call by
pushing the flags on the stack, then doing a far call to the address of
the handler they replaced (the address that occupied the related slot in
the IVT when they were installed). This was, for example, how resident
anti-virus programs were implemented in DOS, and I suppose that other
programs like DoubleSpace and SmartDrive used it too.

For modern OSes, once the initial stage has loaded the kernel and the
relevant modules, it usually fires up its own disk drivers that reflect
the "true" (as defined by the disk controller) order of the HDs, so
neither the BIOS nor drivemap affect that. Moreover, many OSes currently
select their root device based on its UUID, label, etc, so there is no
problem switching the BIOS routines because they won't be used again
after the initial loader is finished. The exception is, of course,
FreeDOS, where the drives stay swapped for the whole session because it
has no disk drivers other than those provided by BIOS.

I hope this has reassured you that neither mmap nor drivemap are doing
any "dark things" nor "1980s DOS/BIOS black magic". The only BIOS data
table modified (by mmap) should be the "available free memory" at the
BDA, which is a completely documented procedure and quite about the only
way of telling a DOS "do not use this memory".

Uhh... btw, I think I found the problem with mmap and FreeDOS: both the
mmap int handler and the drivemap int handler reserve their memory as
high as possible under 1M. Is FreeDOS aware of this? I mean, we can tell
it not to touch memory under 640K through the BDA and INT12, but how do
we tell it not to touch the 640K-1M area? I will check if this is the
cause of the disaster... tomorrow - it's 4AM and I'm sleepy. Goodbye!

-- Lazy, Oblivious, Rational Disaster -- Habbit

Attachment: signature.asc
Description: Esto es una parte de mensaje firmado digitalmente

reply via email to

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