CC'ing Zygmunt as fyi for skills requirements On Tue, 2016-02-09 at 14:00 +0100, David Henningsson wrote: > Hi snappy-devel, > > I've been working on packaging PulseAudio for snappy in order to > enable > apps to play back audio. I've come as far as I need to have the > permissions conversation with someone more familiar with snappy. > You probably want to talk to me. :) First off, is this for 15.04 or 16.04? If 16.04, as Mark said, we want to move to a skills-only approach.
> PulseAudio needs to do at least these things: > > * Listen to a UNIX socket where clients can connect (there are a > few > options w r t where this socket could be located so clients find it). > This is possible with the 'socket' options in the yaml for 15.04. For 16.04, this is still available but I imagine this is going to change in favor of a skills approach that is TBD for sockets. > * Access ALSA sound cards, i e ioctl device nodes under > /dev/snd/*. > (Note: UNIX permissions of these nodes might need adjustment too > depending on solution) > You would use hw-assign on 15.04 and the skills approach on 16.04 (not yet implemented for /dev/snd/* devices). > * Listen to udev events to tell when new sound cards appear in the > system (e g, someone might connect a USB headset). > You would need (hand-crafted) security-policy for this on 15.04. We'll want to take a close look at what this is doing as I imagine this would need to fall under an 'audio-manager' (or audio-managing) skill. > * Get on the system D-Bus in order to speak with the bluetooth > daemon > (in order to enable audio I/O through bluetooth headsets). > Use 'bus-name' and set 'type: framework' on 15.04. On 16.04, this, you guessed it, will be skills based (not yet implemented but needed for several things (eg, bluez)). > * Gain real-time priority in order to have low-latency audio > working > without glitches. > This sounds like a pure security skill. > > Right now, I'm not sure whether PulseAudio should run as a user-level > or > system-level daemon - I expect this will affect what solutions we > choose > for security too. > Snappy doesn't currently have the concept of user services, so sounds like system-level is the way to go for now. > So far I've been working with customizing snapcraft.yaml only, but > maybe > this reaches beyond what snapcraft can handle and some special > apparmor > and/or seccomp profiles need to be crafted. Not sure about this > either? Once the skills work is farther along we'll define a way for people to engage with the snappy team for requesting new skills. For now, I suggest working with me on irc or off-list so I can help unblock you and so we (zyga and I) can work out what this snap needs and can work out the skills needed for 16.04. -- Jamie Strandboge | http://www.canonical.com
signature.asc
Description: This is a digitally signed message part
-- snappy-devel mailing list snappy-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel