Future of libslirp in QEMU

Future of libslirp in QEMU

[Anders Pitman]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

I noticed in the 7.0 changelog that libslirp might be removed as a submodule in the future. Since user networking is very important for my project, I'm wondering if this is simply an implementation detail, or if there are plans to eventually remove slirp support entirely from QEMU (which would be bad for me)?

Is there somewhere I can read the discussion about this? I searched the mailing list archives but didn't see anything obvious.

[-- Attachment #2: Type: text/html, Size: 617 bytes --]

Re: Future of libslirp in QEMU

[Daniel Henrique Barboza]

On 4/20/22 16:08, Anders Pitman wrote:
> I noticed in the 7.0 changelog that libslirp might be removed as a submodule in the future. Since user networking is very important for my project, I'm wondering if this is simply an implementation detail, or if there are plans to eventually remove slirp support entirely from QEMU (which would be bad for me)?
> 
> Is there somewhere I can read the discussion about this? I searched the mailing list archives but didn't see anything obvious.

QEMU will still be supporting libslirp. The difference is that now QEMU will be
using libslirp from the distro instead of packaging it itself.

The relevant thread is here:

https://lists.gnu.org/archive/html/qemu-devel/2022-04/msg00974.html


Thanks,


Daniel

Re: Future of libslirp in QEMU

[Anders Pitman]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

Awesome, thanks.

Apparently I'm not properly performing a date-sorted search on the list archives. I started here:

https://lists.gnu.org/archive/html/qemu-devel/

Then entered "slirp" and searched with chronological order, but the latest entry is from 2020. What am I doing wrong?

Thanks,
//anders

On Wed, Apr 20, 2022, at 2:21 PM, Daniel Henrique Barboza wrote:
> 
> 
> On 4/20/22 16:08, Anders Pitman wrote:
> > I noticed in the 7.0 changelog that libslirp might be removed as a submodule in the future. Since user networking is very important for my project, I'm wondering if this is simply an implementation detail, or if there are plans to eventually remove slirp support entirely from QEMU (which would be bad for me)?
> > 
> > Is there somewhere I can read the discussion about this? I searched the mailing list archives but didn't see anything obvious.
> 
> QEMU will still be supporting libslirp. The difference is that now QEMU will be
> using libslirp from the distro instead of packaging it itself.
> 
> The relevant thread is here:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2022-04/msg00974.html
> 
> 
> Thanks,
> 
> 
> Daniel
> 
> 

[-- Attachment #2: Type: text/html, Size: 1941 bytes --]

Re: Future of libslirp in QEMU

[Cornelia Huck]

On Wed, Apr 20 2022, "Anders Pitman" <anders@apitman.com> wrote:

> Awesome, thanks.
>
> Apparently I'm not properly performing a date-sorted search on the list archives. I started here:
>
> https://lists.gnu.org/archive/html/qemu-devel/
>
> Then entered "slirp" and searched with chronological order, but the latest entry is from 2020. What am I doing wrong?

FWIW, I'd recommend searching the qemu-devel mailing via public inbox on
lore:

https://lore.kernel.org/qemu-devel/

[I got the same outdated results on the page you listed, no idea what is
wrong there.]

Re: Future of libslirp in QEMU

[Paolo Bonzini]

On 4/20/22 21:08, Anders Pitman wrote:
> I noticed in the 7.0 changelog that libslirp might be removed as a 
> submodule in the future. Since user networking is very important for my 
> project, I'm wondering if this is simply an implementation detail, or if 
> there are plans to eventually remove slirp support entirely from QEMU 
> (which would be bad for me)?

No, libslirp is now a standalone project and we'll rely on distros to 
provide the package for the library (and a -devel package that 
meson/pkg-config can use to find whether the library exist).

Paolo

> Is there somewhere I can read the discussion about this? I searched the 
> mailing list archives but didn't see anything obvious.