Well we'd have to ask Colin's input how much of a pain this would be..., but
maybe we could make a raw net userland block device for Win32API & then just
use it or the LINUX equivalent on the host side..... which would be roughly
the same as having a LAN inside of your machine. As for the guest end...,
then we could just use any reasonable good NE2k-pci hardware
emulation--which should be easier than, say a 3Com emulation--because NE2k
is about as brain-dead simple as working ethernet gets.
Drew Northup, N1XIM
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of calberty
> Sent: Thursday, November 02, 2000 5:49 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Network cards
>
>
> Why not do like VMware and emulate a nic on your host machine and
> then emulate
> a nic on the guest os and have the guest os's nic connect to the
> host machine's
> nic as though there were a real network there
>
> Colin Davidson wrote:
>
> > As the subject is coming round to peripherals, and I'm just
> compeleting an
> > NDIS NIC
> > driver (windows MAC driver), I thought I'd add my 2c worth.
> >
> > Having 2 (or more) OSs accessing a network card at the same
> time, totally
> > ignorant
> > of each other, is somewhat undesirable (virtually guarantees
> that networking
> > won't
> > work for either OS). So, what to do... For windows as the guest, one
> > approach would
> > be to create a standard NDIS driver and punt the actual operation to the
> > host. This
> > would be easiest if the Windows networking was TCP/IP based. This is the
> > usual case
> > anyway. All IP traffic could be punted to the host OS, leaving
> only a few
> > oddballs
> > (like DHCP and ARP) that may have to be directly emulated. NIC addresses
> > could be
> > a problem for DHCP and ARP, but I'm sure we can work around it
> somehow - by
> > setting
> > the adapter into promicuous mode, if nothing else.
> >
> > This would involve spoofing the PCI bus, so that the windows
> guest thought
> > it had
> > a suitable NIC to play with, figuring some mechanism to pass
> requests to the
> > host
> > to the guest, writing a guest handler to redirect the network traffic,
> > implementing
> > a "virtual interrupt" mechanism whereby the host could cause
> the guest OS to
> > "see"
> > a hardware interrupt and of course, writing a NIC driver for
> windows that
> > will
> > work with Plex86 (and provide a suitable NIC address - one that won't
> > conflict with
> > the rest of the LAN).
> >
> > I just had another thought. There's no reason why the sends and receives
> > could not
> > work at the ethernet, except that the host would have to
> recognize both its
> > own NIC
> > address and the Guest NIC address - could be done in
> promiscuous mode, with
> > the host
> > driver filtering (this could be costly in machine cycles)... In
> this case,
> > we would
> > have to make sure that the host driver would recognize its own
> NIC address,
> > and
> > loop-back any packets that the Guest sent to it.
> >
> > Either way, we would want a virtual card for windows, and a
> driver to handle
> > it, a
> > virtual interrupt mechanism, PCI spoofing, a communication
> mechanism to the
> > host
> > from the guest and vice-versa. Thinking about it, PCI spoofing
> is probably
> > going to
> > play a big role in peripheral handling, whatever it is. This is
> probably a
> > VIP
> > (Very Important sub-Project).
>
>
