Why does bus mastering cause a problem?
----------------------------
If the device talks to a driver under an OS, the driver
"knows" what to do.
If the driver goes through your MUX, or is "emulated",
it can still use bus mastering, at the expense of an
additional copy (or, if you are very diligent, a
virtual mapping). Again, no particular problem.
The only problem I can see is if the bus mastering
device cannot see the memory that you wish to map.
[eg. some old boxen don't permit bus mastering to
access more than the first 16mb of storage]. In which
case you have to deal with 2 kinds of memory, but the
"native" driver has to deal with that anyway.
Of course, you are talking about creating potentially
multiple models for a series of devices, including
some that haven't been invented yet.
----------------------------------
What you need is a DEVICE DESCRIPTOR LANGUAGE, that
can define the physical characteristics of an
unknown device. The DDL can be used to generate
an intercepting driver "on the fly". DDL has to
descriptive enough to define ports/memory/mastering
and expected consequences [EG. Write to this port will
or may result in interrupt being delivered].
The DDL can be used to provide a "port modeling"
view of the device -- not what it actually DOES, but
how the ports/memory/interrupts/mastering BEHAVE.
DDL can be used statically to generate templates,
and dynamically to provide "pass-through" devices.
Most of the DDL actions should already be provided
for in the Plex86 framework (I am working on something
similar, but with somewhat different methodologies --
so I haven't read Plex86 source, I just don't know).
The actions that are (probably, again I don't know)
missing are the "expect" actions; basically the
device register etc state transitions that can occur.
If something like this is layered in, then a new
device can be easily supported if the register/memory/interrupt
and state data are known. You can also detect a
bad driver, *or* bad hardware if it falls off the state
graph (this may also be something that the hardware vendor
hasn't documented, which would aid in hardware problem
resolution).
Ratboy.
----Original Message Follows----
From: Jens Nerche <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: P.S. devices
Date: Fri, 16 Jun 2000 10:40:34 +0200
MIME-Version: 1.0 (generated by tm-edit 7.106)
Received: from [212.204.201.31] by hotmail.com (3.2) with ESMTP id
MHotMailBB133377004ED82197BCD4CCC91F0E470; Fri Jun 16 01:42:52 2000
Received: by lightning.fastxs.net (Postfix, from userid 0)id C9788E8017;
Fri, 16 Jun 2000 10:40:50 +0200 (CEST)
Received: from os.inf.tu-dresden.de (os.inf.tu-dresden.de [141.76.48.100])by
lightning.fastxs.net (Postfix) with ESMTP for <[EMAIL PROTECTED]>id
0AEE7E8017; Fri, 16 Jun 2000 10:40:40 +0200 (CEST)
Received: (from jn4@localhost)by os.inf.tu-dresden.de
(8.9.3/8.9.3/Debian/GNU) id KAA04771;Fri, 16 Jun 2000 10:40:34 +0200
>From [EMAIL PROTECTED] Fri Jun 16 01:47:28 2000
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Message-Id: <[EMAIL PROTECTED]>
In-reply-to: <[EMAIL PROTECTED]> (message from
JensNerche on Thu, 15 Jun 2000 16:07:02 +0200)
Sender: [EMAIL PROTECTED]
Precedence: bulk
One point I want to emphasize (because discussion went some times
about guest driven devices): if a device uses busmastering and
writes into RAM directly, we have no chance to control access.
Same with read, of course. We would have to virtualize busmastering
for each device at least, but as far as I know there is no standard
for that. This means, we need a driver stub for each device and thats
_a lot_ of work... Even if we are able to extract from Linux or
OSKit (licence problems?)...
So I see the chance for devices driven by guests only for simple
devices, but the interesting, new ones, for which that would be nice,
bring us headaches :(
jens
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
