[pulseaudio-discuss] [PATCH v3 00/11] Introduce memfd support
Ahmed S. Darwish
darwish.07 at gmail.com
Tue Mar 22 00:56:59 UTC 2016
On Mon, Mar 21, 2016 at 10:01:14AM +0100, David Henningsson wrote:
>
> On 2016-03-12 23:35, Ahmed S. Darwish wrote:
> >Hello!
> >
> >The simplified memfd patch series ;-)
>
> Hi!
>
> Good work!
>
> I've read through the patch series and think they look pretty much okay, and
> your amount of testing is exemplary.
>
Thanks a lot .. couldn't do it without everyone's help here :-)
Also, regarding the testing, I really did not want to increase
anyone's Launchpad bugfixing workload ;-)
> Surely there are nitpicks here and there but at this point I think maybe
> we're better off merging the patch series as it is to get wider testing from
> developers using it in practice.
>
Great, I'll be around if there's anything in need of a fix.
> My only concern or thought is about the global mempool. By turning that into
> a memfd by default, we would potentially slow down clients which support
> posix shm but not memfd. I'm not sure if this is a problem in practice
> though - even an old closed-source client would (hopefully?) bind to a new
> libpulse library and thus gain memfd support that way, and I hope nobody
> links libpulse statically. Thoughts?
>
Alexander mentioned the SteamOS case, where "they don't link
statically, but have a 'known-good' copy of the library packaged
and put into LD_LIBRARY_PATH, and it may be next to impossible to
explain to the users how to upgrade it."
I'm sure though that even if they have a 'known-good' copy, they
keep the daemon version in-sync with the library version? I can't
think of any sane reason not to do so..
Anyway, if that case is indeed problematic, maybe we can lobby
them a bit to do a proper distribution of PA? If anyone has some
contacts, I'll be glad to open a communication channel..
Thanks,
--
Darwish
http://darwish.chasingpointers.com
More information about the pulseaudio-discuss
mailing list