* Markus Armbruster (arm...@redhat.com) wrote: > Thomas Huth <th...@redhat.com> writes: > > > On 2018-11-14 15:46, Markus Armbruster wrote: > >> Thomas Huth <th...@redhat.com> writes: > >> > >>> On 2018-11-14 13:59, Markus Armbruster wrote: > >>>> Marc-André Lureau <marcandre.lur...@redhat.com> 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 / dgilb...@redhat.com / Manchester, UK
