From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jakub Vana <gugux@centrum.cz>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: x86 - Realmode BIOS and Code calling module
Date: Thu, 12 Aug 2004 21:30:54 +0100 [thread overview]
Message-ID: <1092342654.22362.61.camel@localhost.localdomain> (raw)
In-Reply-To: <20040812133854Z2097966-29039+40063@mail.centrum.cz>
On Iau, 2004-08-12 at 14:38, Jakub Vana wrote:
> > Why is this better than LRMI in user mode.
>
> I was now looking on LRMI. It must be a nice code, but It is still only
> V86 emulation. I have listen that some BIOSes use something called
> Unreal mode, that is realmode with segment registers used like in
> protected mode. There is only one way, how to set this segregs -
> switch to prot. mode, but if the BIOS try to switch when is running
> in V86 CPU generates #GP (Global Protection fault). Not if it is
> running in real Real Mode.
I've yet to meet a video bios that does this. I don't think the X folks
have either, but you could run it past Egbert to make sure. The
"unreal" mode is normally only in existance during early boot.
>
> > To do BIOS calls safely
> > you need to be very careful about things like PCI locking, I/O
> > emulation and the ROM scribbling
>
> I'm not sure abou this, but I think there is not problem in calling
> BIOS, here is problem in BIOS handling with this features and so
> It's the problem of programmer that calls the BIOS to safely work
> and synchronize his hardware in kernel with BIOS. Other hardware
> (that is not pawn by BIOS) can't make problems.
One example is PCI configuration accesses which must be co-ordinated
with the kernel, and through the kernel PCI interfaces.
next prev parent reply other threads:[~2004-08-12 21:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-12 13:38 x86 - Realmode BIOS and Code calling module Jakub Vana
2004-08-12 20:30 ` Alan Cox [this message]
2004-08-13 7:44 ` Vojtech Pavlik
-- strict thread matches above, loose matches on Subject: below --
2004-08-14 20:10 Jakub Vana
2004-08-13 14:36 Jakub Vana
2004-08-13 21:54 ` Alan Cox
2004-08-12 9:36 Jakub Vana
2004-08-12 11:56 ` Alan Cox
2004-09-06 15:27 ` Jozef Vesely
2004-09-06 17:03 ` Alan Cox
2004-08-12 12:39 ` Grzegorz Kulewski
2004-08-12 12:50 ` Vojtech Pavlik
2004-08-16 7:49 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1092342654.22362.61.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=gugux@centrum.cz \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.