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
client API?
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
module-preference-manager.
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
/etc/pulse/default.pa.d/90-load-very-evil-module.pa
that loads an evil module, and then a
~/.config/pulse/default.pa.d/90-load-very-evil-module.pa
...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.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
