[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a stand
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project |
Date: |
Wed, 14 Nov 2018 18:14:36 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
* Markus Armbruster (address@hidden) wrote:
> Thomas Huth <address@hidden> writes:
>
> > On 2018-11-14 15:46, Markus Armbruster wrote:
> >> Thomas Huth <address@hidden> writes:
> >>
> >>> On 2018-11-14 13:59, Markus Armbruster wrote:
> >>>> Marc-André Lureau <address@hidden> writes:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> Based-on: https://people.debian.org/~sthibault/qemu.git/ slirp branch
> >>>>>
> >>>>> This series goal is to allow building libslirp as an independent
> >>>>> library.
> >>>>>
> >>>>> While looking at making SLIRP a seperate running process, I thought
> >>>>> that having an independent library from QEMU would be a first step.
> >>>>>
> >>>>> There has been some attempts to make slirp a seperate project in the
> >>>>> past.
> >>>>> (https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg01092.html)
> >>>>> Unfortunately, they forked from QEMU and didn't provide enough
> >>>>> compatibility for QEMU to make use of it (in particular, vmstate
> >>>>> handling was removed, they lost git history etc). Furthermore, they
> >>>>> are not maintained as far as I can see.
> >>>>>
> >>>>> I would propose to make slirp a seperate project, that can initially
> >>>>> be used by QEMU as a submodule, keeping Makefile.objs until a proper
> >>>>> shared library with stability guarantees etc is ready..
> >>>>>
> >>>>> The subproject could created by preserving git tags, and cleaning up
> >>>>> the code style, this way:
> >>>>>
> >>>>> git filter-branch --tree-filter "if ls * 1> /dev/null 2>&1; then
> >>>>> clang-format -i * /dev/null; fi " -f --subdirectory-filter "slirp"
> >>>>> --prune-empty --tag-name-filter cat -- --all
> >>>>> (my clang-format
> >>>>> https://gist.github.com/elmarco/cb20c8d92007df0e2fb8a2404678ac73)
> >>>>>
> >>>>> What do you think?
> >>>>
> >>>> Has the slirp code been improved to be generally useful? I still got it
> >>>> filed under "friends don't let friends use that, except for testing"...
> >>>
> >>> The slirp code is already used in a lot of other projects:
> >>
> >> The issue I have with SLIRP isn't that it solves a useless problem (au
> >> contraire!), it's that it's a useless solution.
> >
> > Ouch, that was completely arrogant and inappropriate. It's far away from
> > being useless,
>
> ... as I immediately admit ...
>
> > and Samuel is doing a very good job in picking up all the
> > patches and fixes that have been posted in the past months. Have you had
> > a look at the changelog at all before you wrote that sentence?
>
> ... right in the next sentence:
>
> >> Okay, that's an unfair
> >> exaggeration, it's not useless, I just wouldn't trust it in production,
> >> unless it has improved significantly since I last looked at it.
>
> If my joke offended Samuel, or anyone, I offer my sincere apologies.
>
> > Nobody said that the slirp code would suddenly be perfect, but if it's
> > getting even more traction and attention as a separate library (since
> > other projects might contribute their fixes back "upstream" in that
> > case), it could really get a solid building block for a lot of emulators
> > and similar software.
> [...]
>
> I'm afraid we're in violent agreement there. I wrote:
>
> >> No objections to spinning it out, as long as it comes with a fair
> >> assessment of its limitations.
> >>
> >> Turning it into a proper project might even improve its chances to
> >> get improved towards production quality, compared to its current
> >> existence as a corner of QEMU next to nobody wants to touch.
One thought is that it might actually be the best standalone stack
around at the moment; I mean while I'm seeing people objecting
to bits of SLIRP, I'm not seeing anyone saying
'Why don't you just use ....'
Dave
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- [Qemu-devel] [PATCH for-3.2 41/41] build-sys: add a basic meson build, (continued)
- [Qemu-devel] [PATCH for-3.2 41/41] build-sys: add a basic meson build, Marc-André Lureau, 2018/11/14
- [Qemu-devel] [PATCH for-3.2 40/41] slirp: replace remaining QEMU dependency, Marc-André Lureau, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Markus Armbruster, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Richard W.M. Jones, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Thomas Huth, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Markus Armbruster, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Dr. David Alan Gilbert, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Richard W.M. Jones, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Thomas Huth, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Markus Armbruster, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project,
Dr. David Alan Gilbert <=
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Daniel P . Berrangé, 2018/11/14
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Stefan Hajnoczi, 2018/11/14