Eric Laberge wrote:
>
> I was looking at Drew's PC schema, and was wondering how good it is to really
> mimic the PC architecture. The more steps we put between a device and the
> CPU, the slower it might get, especially when the only interaction comes from
> IO ports which can be registered to be directly called. However, it gives a
> very clean look to the project and to future programmers to have things
> separated.
> Here comes my topic, why not go all the way to creating a south bridge
> device, if we intend to make a hierarchy? (Here is a schema of the KT266:
> http://www.via.com.tw/jsp/en/products/KT266-Brochure-page1.jpg ) This way
> only a single interface is needed between the core developpers and the
> peripheral developpers, and it would be a nice thing that could be ported to
> Bochs.
> The project specific stuff are indeed the north bridge (CPU and RAM handling).
>
> Would this be something to think of before trying to implement the PCI bus?
I've been reading PCI info too. There's no real reason to implement
"the PCI bus". Like everything else, we have to offer emulation
of the environment from a programmatic view. What we'd need to
model is mostly the configuration space stuff.
Yeah, essentially the cluster of devices from bochs becomes the
logic handled by the south bridge and anything South of that.
The south bridge doesn't necessarily build in all legacy IO.
Anyways, if you want the SB to report the legacy builtin
components during enumeration, you still have to have some
extra code.
Bochs has different requirements from plex86 for some hardware
since at times it is much better for performance, that certain
components be emulated in the VM monitor space, rather than
in host user space. This is one reason it would help to move
device emulation to a plugin architecture. C++ also makes
life difficult. Since I originally just converted bochs from
C to C++, and have a philosophy of not using fancy C++ facilities,
it was easy to reverse this for a few components. But this could
be difficult if you want to maintain code which can play with
either environment. Well, actually 3 environments:
(1) Bochs
(2) Plex86 user space
(3) Plex86 VM monitor space.
The last one requires C, at least for parts of emulation that
is desirable to be moved there for performance.
I'm still thinking a little on this myself, but perhaps a
reasonable thing to do is as follows.
- Modify the interface for IO emulation to a plugin architecture
for both plex86 and bochs. At least then the devices could be shared
immediately, even if the calling code is different.
- As only certain modules are converted to C, it would be nice if we could
agree to maintain the C version. These would be the components which
have to be moved to the VM space for performance. A version in C with
a good interface, may allow one to conditionally link it with the
plex86 kernel code OR compile it for use as a dynamically link/loaded
object.
- Perhaps we could also agree on a spec which would allow for the
main logic to drive the IO devices (a south bridge like cluster)
to be shared by both projects as well.
I'd also like to merge the BIOS.
Thoughts welcome...
-Kevin
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Lawton [EMAIL PROTECTED]
MandrakeSoft, Inc. Plex86 developer
http://www.linux-mandrake.com/ http://www.plex86.org/
