[Spice-devel] autoconf for slirp

[Alexander Larsson]

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 
       alexl at redhat.com            alexander.larsson at 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!