On Wed, 2010-03-31 at 08:52 +0300, Yonit Halperin wrote:
> On 03/28/2010 02:30 PM, Alexander Larsson wrote:
> > On Sun, 2010-03-28 at 09:03 +0300, Yonit Halperin wrote:
> >> On 03/26/2010 11:45 AM, Alexander Larsson wrote:
> >>> On Fri, 2010-03-26 at 10:25 +1000, Dave Airlie wrote:
> >>>> this is quick and dirty, and not completely tested yet, but it
> >> makes
> >>>> my life a little bit easier, since I
> >>>> don't install stuff in /usr ever.
> >>>
> >>> I took this, cleaned it up and made it pass distcheck and
> commited.
> >>>
> >>> However, whats the general deal with us maintaining a copy of the
> >> slirp
> >>> code from qemu? That code is in turn a cut and paste from an
> already
> >>> existing (autoconf-using) upstream library at:
> >>>
> >>> http://slirp.sourceforge.net/
> >>>
> >>> Why are we not using that? And if we have good reasons, why don't
> we
> >>> call our copy something that does not conflict with the original
> >>> package?
> >>>
> >>
> >> It is not the same as the upstream code. The main change: the
> original
> >>
> >> code transfers the application layer of the packets to its
> destination
> >>
> >> by using BSD sockets. We changed it to use a general interface for
> >> socket, so we can use it to pass the packets to spice (tunnel
> >> channel).
> >> No problem to change the name of the package...
> >
> > How extensive is the changes? Could they be made such that its just
> a
> > patch to the upstream version, supporting both BSD sockets and a
> generic
> > interface?
> >
>
>
> http://slirp.sourceforge.net/ wasn't updated since 2006.
> The changes are not minor and they also contain additions/fixes that
> were preformed in Qemu. If in the future we decide that the network
> redirection solution is part of spice, we should discuss how to handle
Well, we could ask them, maybe we can just take over as upstream? I
dunno, i have not looked at slirp in detail.
> the Slirp issue and we can try to revive this project, though its
> original aim is different than ours. For now, since network
> redirection
> is not a top priority feature, we can insert ifdefs to the tunnel
> worker, remove for now the dependency on slirp, till we continue with
> this feature.
This sounds like an excellent short-term solution!
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
al...@redhat.com alexander.lars...@gmail.com
He's a lonely neurotic firefighter on the edge. She's a manipulative
kleptomaniac mechanic with the soul of a mighty warrior. They fight crime!
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
