Re: [libvirt PATCH] news: Document that we build with musl
On Wed, Mar 09, 2022 at 01:14:39PM +0100, Michal Prívozník wrote:
On 3/9/22 11:36, Daniel P. Berrangé wrote:
> On Wed, Mar 09, 2022 at 11:27:22AM +0100, Martin Kletzander wrote:
>> A bit of effort by me and Michal helped make this the case, and it helped us
>> uncover some potential issues. I am not documenting it as supported or adding
>> an Alpine container into the CI, but since there were some distribution bugs
>> mentioning libvirt issues I thing it would be nice of us to notify those
>> distribution maintainers that read our release news.
>>
>> Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com>
>> ---
>> NEWS.rst | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/NEWS.rst b/NEWS.rst
>> index a5b6106bc2c2..f0270b9bb159 100644
>> --- a/NEWS.rst
>> +++ b/NEWS.rst
>> @@ -21,6 +21,9 @@ v8.2.0 (unreleased)
>>
>> * **Bug fixes**
>>
>> + * Both build and tests should now pass on Alpine Linux or any other
>> + distribution with musl libc.
>
> IMHO even though you don't say it explicitly, anyone reading this
> will interpret it at meaning libvirt is expected to work with
> musl, which is misleading
With everything turning into a container nowadays, I believe it's time
to revisit our decision of supported platforms. Or even if we don't want
to support Alpine, that's fine, but perhaps have it CI, allow it to fail
(just like we're doing for rawhide/sid) and see if we still compile? The
benefit would be more portable code (like Martin's patches from past
week demonstrate).
I'm not saying we shouldn't support Alpine, just that I don't believe
it works today, and making it work is not an quick & easy change at
all.
Unlike the other C libraries we deal with, musl doesn't allow you to
use malloc after fork in a threaded application, and will deadlock.
This is a difficult problem for us to address given what we expect
to be able todo in the fork/exec scenario in libvirt. The behaviour
we expect is not required by POSIX, but Linux(glibc)/macOS/FreeBSD
platforms have allowed it anyway, because without it, writing
threaded apps which fork is much more difficult.
It will require alot of work to virCommand, most likely involving
a switch to use of posix_spawn, while also removing the ability to
run callback hooks, and anything else we do inbetween fork/exec,
that is not covered by posix_spawn features.
This hook removal would in turn require significant changes to the
QEMU driver, probably requiring us to create a helper program. We
would exec libvirt_qemu, which does what we used todo in the hook,
and then libvirt_qemu would have to exec the real QEMU in place
of itself.
This is all likely useful long term, but not quick or easy and is
quite likely to introduce regressions as we work through it.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|