Re: [Qemu-devel] [PATCHv9 0/10] slirp: Adding IPv6 support to Qemu -net user mode

[Thomas Huth]

On 07.03.2016 12:19, Samuel Thibault wrote:
> Jason Wang, on Mon 07 Mar 2016 14:48:16 +0800, wrote:
>> - Lots of checkpatch warnings, let's try to silent it.
> 
> They are indentation issues, yes. They are already existing in slirp/
> . Whenever new code was added we sticked with the qemu style, but for
> patched code we prefered to stick to the existing indentation, since
> otherwise it'd mean reindenting it all to keep the functions readable at
> all. Do you what to see the whole slirp directory be reindented once for
> good before this gets applied? Personally I just don't care which way or
> the other.

IMHO we should reindent the whole slirp folder to the correct QEMU
coding style at one point in time, or this topic will pop up again and
again for each future patch to the slirp sources in the future.
But I think it should be postponed until the IPv6 patches have been
included to avoid yet another unnecessary reiteration.

>> - I expects a unit-test for this. You may want to have a look at the
>> pxe-test in tests/, I think it could be extended to test ipv6 slirp somehow.
> 
> It doesn't seem so simple to me. In the case of PXE, you have a guest
> implementation of PXE inside the BIOS. In the case of IPv6, I don't
> think you have a guest implementation of IPv6 in the BIOS... So we'd
> need to embed some guest that would do the IPv6 stuff. At best we can
> make a qtest_start(), and that's about it.

Maybe we can use qemu-system-pppc64 for this ... the SLOF firmware has
support for IPv6 already. I can have a look at this if you like.

> I'm awfully tired of all of this. This work has been done 3 years ago,
> has already seen 9 iterations. Had it not been something important to
> my eyes (being able to easily test ipv6), I would have abandoned a long
> time ago.

I can fully understand you ... it's always the problems with parts of
QEMU where there is no active maintainer available - the other parts of
QEMU normally work much better. Since Jan does not have time for slirp
anymore, we really urgently need a new maintainer for that code ... (but
let's discuss that in the other mail thread).

 Thomas