[pulseaudio-discuss] RFC: Getting rid of the GConf dependency
david.henningsson at canonical.com
Tue Jan 29 07:27:28 PST 2013
On 01/29/2013 02:47 PM, Tanu Kaskinen wrote:
> On Tue, 2013-01-29 at 12:03 +0100, David Henningsson wrote:
>> On 01/29/2013 11:01 AM, Tanu Kaskinen wrote:
>>> The new "manager modules" that I suggested could store their settings
>>> as .pa scripts. Would that be enough to make you happy?
>>> The scripts could be stored in a location from which they would get
>>> picked up automatically by the main configuration script, or the scripts
>>> could be stored in a location from which they would only get picked up
>>> by the manager modules.
>>> If the scripts were included automatically by the main configuration
>>> script (default.pa), that would have the problem that when a manager
>>> module is removed from the configuration, its settings are not cleared
>>> automatically. So if the user removes module-rtp from the configuration,
>>> unwanted rtp modules may still get loaded. Therefore, I'd prefer the
>>> manager modules to control the module loading instead of including the
>>> scripts from the main configuration script.
>>> I don't think the settings storage format makes a big difference when
>>> trying to figure out why a specific module is loaded,
>> What makes it easier to figure out, would be
>> 1) less files/directories to look in
>> 2) less number of ways to load a module
>> GConf fails in both of the above. I was hoping we could do better.
>> > so maybe you're
>> > having problem with the whole "manager module" concept?
>> Maybe so.
>> If we try to design this from the client's perspective, i e paprefs or
>> possibly other apps in the future, we would essentially need these
>> function additions to the client API:
>> * Is a module loaded by default on startup (set/get)
>> * Module parameters (set/get)
>> * Possibly a way to get/set in what order modules are loaded at
>> startup, but not sure if this is really needed.
> I'm not sure if I expressed this clearly: in my proposal clients won't
> manage modules directly. For example, paprefs wants to enable network
> access, and pulseaudio provides an interface for that exact operation.
> paprefs doesn't tell pulseaudio to load module-native-protocol-tcp and
> module-dbus-protocol with argument "access=remote". Instead, whatever
> code implements the "enable network access" operation will control what
> modules will need to be loaded with what parameters.
This sounds like an abstraction layer. I doubt the abstraction layer is
worth the added complexity here - paprefs is a very PA specific utility
anyway, so referencing module names directly would be okay.
> One reason why I want to avoid requiring clients to manage the modules
> directly is that clients would need to understand what the set of
> currently loaded modules means. If there are two
> module-native-protocol-tcp instances (with different parameters), one of
> which is the result of the user checking the "enable network access"
> checkbox and one is a manually loaded instance, how is paprefs going to
> tell them apart? Unchecking the "enable network access" checkbox
> shouldn't unload the manually loaded module.
I'm not so sure about this either. If a module-native-protocol-tcp is
loaded - no matter what parameters - there is some network access
enabled, and thus it would make sense to check the box in paprefs.
I would also guess people use paprefs for simplicity (if they use it at
all?), and if they set up module-native-protocol-tcp connections
manually, they are unlikely to use paprefs too (at least for that thing).
> paprefs could set some
> magic property on the modules that it manages, but what if there's
> another application that also wants to control the same "enable network
> access"? The magic property would need to be standardized. Not
> impossible, but managing the modules at server side would be less hairy.
> Having an abstract API instead of direct module management is desirable
> also from security point of view: we might want to allow clients
> operations that result in modules being loaded or unloaded without
> allowing direct module loading and unloading.
Hmm, I thought module (un)loading was possible through the client API,
but maybe it isn't.
But if we're worried about security - isn't the stuff that paprefs can
do today just as harmful as module (un)loading anyway? If so, maybe
paprefs should use a pacmd type approach rather than extending the
OTOH, having a more open approach enables people to write their own PA
configurators without having explicit support for that in PA.
>> Now whether this is all handled by a "manager module" or by the core is
>> an implementation detail, but it seems weird if a manager module could
>> remove itself (and I fail to see any point in having several manager
>> modules?), so probably it makes more sense to have it in the core.
> Thoughts about one vs. multiple manager modules: The reason why I
> suggested separate manager modules such as module-zeroconf and
> module-raop was just to keep e.g. knowledge of raop strictly separated
> to the raop modules. Having thought about this a bit, I think a single
> module would be actually nicer. With separate manager modules
> module-raop would be loaded by default, which would probably cause users
> to wonder "I have module-raop loaded, why don't I have any raop
> sinks?" (answer: the "discover raop devices" option isn't enabled) and
> "I don't own any raop devices, why is pulseaudio having module-raop
> loaded?" (answer: so that paprefs can interact with it).
...and less copy-paste between module loading modules.
> From client point of view it shouldn't make any difference whether the
> "discover raop devices" option is implemented by module-raop or by
>> Second, to be able to accurately answer "is a module loaded by default
>> on startup", I assume such code would have to go through all the .pa
>> scripts in all directories.
> As long as there are modules that load other modules, you can't answer
> the question reliably. Whether module-alsa-card gets loaded depends on
> whether there are any sound cards.
Right; it would only be able to answer that for the "root" modules.
> I wouldn't be against making it a convention to not load any modules
> from other modules, though. There's no reason module-udev-detect must
> create the alsa card object by loading module-alsa-card. There could be
> an API for loading alsa cards, like there is for loading alsa sinks and
> sources. Similarly, there could be an API for controlling raop
> functionality without loading any modules.
>> Exactly how to do a user level override, that e g disables a module
>> loading of a module that is loaded by default for all users, I think we
>> don't have the directory structure to permit that yet, which is why I
>> brought the directory structure thing up.
> I don't see how you could achieve module blacklisting with some clever
> directory layout.
If we have a file
that loads an evil module, and then a
...which is empty, the latter could override the former. I'm not saying
this is the best idea, just that it is possible.
> I think you need to have a way to set some variable
> prior to processing the system-wide configuration, and if you have that,
> then there's no need to care about the directory layout: to prevent
> module-udev-detect from loading, just put "allow-module-udev-detect=no"
> in the beginning of the user's default.pa and then include the
> system-wide default.pa.
Sure, this would work too.
David Henningsson, Canonical Ltd.
More information about the pulseaudio-discuss