public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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. 


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox