On 2016-03-22 01:56, Ahmed S. Darwish wrote:
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..
Aaaand...there we stalled. I could use a second opinion on:
1) Whether to go ahead and merge, despite not promising to be around
much to test it
2) If that merge should include all 11 patches or not.
Given the fact that the possible performance regression only affects a)
input data and b) only old copies of libpulse, I think the chances are
fairly small.
One option could be to merge all patches as-is but on top of that set
"enable-memfd" to default to false for one release cycle; to give Steam
and others a chance to update. That will also give pioneers some extra
time for testing, and report bugs if there are any.
Not to mention the fact that if you play a Steam game, rendering
triangles will probably be a bigger performance concern than
transferring audio data over unix pipes. :-) That said; in the future
packaging libs with the app might be more popular, e g ubuntu-snappy
would to that. Not sure how xdg-app would work in this regard.
// David
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
