From: Paul LeoNerd Evans <leonerd@leonerd.org.uk>
To: jhoger@pobox.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Anyone familiar with the slirp code?
Date: Fri, 22 Jul 2005 19:14:55 +0100 [thread overview]
Message-ID: <20050722181455.GD3558@cel.leo> (raw)
In-Reply-To: <1122050833.6034.400.camel@aragorn>
[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]
On Fri, Jul 22, 2005 at 09:47:13AM -0700, John R. Hogerhuis wrote:
> I don't think the original author anticipated or cared about slirp being
> ported to a 64-bit processor. I won't speak for the quality of the code
> in general, but on a 32-bit machine the pointer size is 32-bit. It's
> perfectly safe on that platform to use any 32-bit spot as a hidey hole
> for your cookies.
Well put.. :)
> Just go for it. The slirp code was imported into qemu. At this point
> you're probably as much an expert as anyone. There is no upstream
> maintainer for the code either, I looked and found and asked the last
> sucker that had maintained it for a bit, and he just wanted to unload
> it.
Well, in this case, it is almost worth pondering if a complete
from-the-top rewrite is required... It might be easiest to look at what
the code is meant to do, from a high level, and re-implement from
scratch. This way, all the required features can be put in from the
beginning, no extra stuff that's not required, and so on... I expect
large amounts of the code can be kept and modified, and the general
layout will remain, but a lot of the data structures will have to
go...
> If you fix it though, be prepared for the fact that you will be the new
> expert ;-)
Hhhmmmm.... I have numerous projects I'm already working on; adding one
more always gets tricky... But we'll see how things pan out...
> One thing I'd like to see long term is to completely remove the NAT code
> and replace it with something more modern and robust like netfilter.
> That would give us a lot of nice application level gateways (nat
> modules) for important protocols, and some tweakable firewall settings
> for user-net.
>
> While I'm wishing, in fact it would be a nice feature in general for
> QEMU to have a built in firewall pointed at each host with fairly
> minimal permissions by default. A windows machine on your network is a
> windows machine on your network, virtual or not :-)
Well, as I said above, this sort of thing could be implemented with a
re-write....
Perhaps we could borrow some of the "iptables" code from the Linux
kernel, and use that..? It would be quite cool, I think, to have
something similar to iptables built into qemu...
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-07-22 21:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-22 15:51 [Qemu-devel] Anyone familiar with the slirp code? Paul LeoNerd Evans
2005-07-22 16:47 ` John R. Hogerhuis
2005-07-22 18:14 ` Paul LeoNerd Evans [this message]
2005-07-22 18:45 ` Gwenole Beauchesne
2005-07-22 22:05 ` Jim C. Brown
2005-07-22 22:53 ` Gwenole Beauchesne
2005-07-23 4:15 ` Jim C. Brown
2005-07-24 18:09 ` Adrian Smarzewski
2005-07-22 22:29 ` Josh Metzler
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=20050722181455.GD3558@cel.leo \
--to=leonerd@leonerd.org.uk \
--cc=jhoger@pobox.com \
--cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.