John R. Hogerhuis wrote
On the user space issue, I guess that's not completely true when
it comes to networking? You have to be using the TUN/TAP driver.
This is something I've been thinking about, and maybe, just maybe, I might
have got an idea to make it work on at least later (host) NT's - the ones
that can give you raw access, allow you to write your own e.g. IP headers.
The most likely protocols to encounter would be IP, followed by ICMP. Should
anyone want IPX, or even NetBEUI - sure, make it a plug-in architecture.
What if some piece of code was given low-level protocol knowledge, to let
the OS'es running in QEMU happily think they talk to a NIC (be it NE2k, or a
card with some more speed and less interrupt requirements), but that the
emulated card in turn was "connected" to a piece of software, let's for now
call it the protocol parser (PP), that also knew IP and ICMP?
I envision this piece of code as either a part of the QEMU process, or a
separate process (let's not bother about the IPC - that's easy in
comparison), parsing the emitted ethernet packets from the QEMU virtual NIC,
and in effect acting as a NAT (and then some).
Sure, it wouldn't run light lightning, but it could be a completely
user-mode solution.
Running this thing as a separate process would probably make it slower, but
it could also enable the possibility to run the QEMU process(es) with less
than Administrator privileges - while the component getting this raw access
to the host NIC obviously would need them. That's the reason I mentioned the
possibility of emulating anopther card than NE2k, which is probably the most
inefficient of all NIC's, even if comparatively easy to implement an
emulator for.
As for the idea about a SOCKS (or any other kind of) proxy; I'm fairly sure
that'd only work for operating systems where a QEMU-special implementation
was created (either by the OS, or in QEMU itself - by trapping syscalls and
so on), why it wouldn't be a viable solution for but some limited cases. OK,
it could probably be done without too much effort for e.g. a specific Linux
version (maybe even many), but from my POV it'd be very fragile in depending
on specific versions of specific OSes.
Please don't see this as a suggestion, I'm just bouncing an idea I've had
for a while.
/Mike
_______________________________________________
Qemu-devel mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/qemu-devel