On 03/25/2013 03:35 PM, Tanu Kaskinen wrote: > On Mon, 2013-03-25 at 09:36 +0100, David Henningsson wrote: >> On 03/22/2013 06:01 PM, Tanu Kaskinen wrote: >>> Hello, >>> >>> I added another GSoC idea to the wiki[1], and it's also copied below. >>> Does the idea make sense? Is there anything in it that should be >>> changed? >> >> Not sure about if I would recommend this one to a GSoC student. It feels >> like we have quite some stuff to figure out w r t to directory moving, >> conf splitting etc, that aren't straight laid out yet. If we get all >> that work thought out, then okay, but if we're unsure of what to do, the >> GSoC student will be even more confused. > > Fair point, I'll remove the project idea from the wiki for now. > >> >>> === Improvements Related to Configuration === >>> >>> '''Problem statement:''' There are a couple of separate problems: >>> * If setting some option in a configuration file doesn't seem to have >>> any effect, chances are that it's being overridden in some other file, >>> but which file? It's slightly tedious to manually look in several >>> directories and check the file contents. It's even more cumbersome when >>> debugging a problem remotely, when it's necessary to explain every step >>> that needs to be performed. >>> * Changing a configuration file requires restarting the server before >>> the change takes effect. >>> >>> '''Suggested solution:''' >>> * When reading configuration files, the daemon should store the origin >>> file of each option separately. This information should then be made >>> possible to query by clients. Then, pactl (a command-line utility for >>> interacting with the server) should be extended to provide a command >>> that prints the configuration of the running server, and also the origin >>> file of each option. This functionality would probably apply only to the >>> "ini-style" configuration files. Those cover most of the !PulseAudio >>> configuration, with the notable exception of the startup script. It >>> might be useful to also record the loaded startup script(s) so that the >>> startup sequence can be queried for debug purposes. >>> * Sending SIGHUP to the server process should cause it to reload its >>> configuration. This too would probably apply only to the "ini-style" >>> configuration files, not to the startup script. It's probably not >>> possible to make all configuration options changeable at run-time, but >>> that's OK. >> >> Hmm. This sounds like a lot of complexity for little gain. And potential >> bugs only affecting those who are using this not-so-widely-used feature, >> I assume. > > Are you referring to the second point only, or both points? Mostly the second, but if it only has support for the .ini-style conf files, maybe the first as well. After all, it seems like we more often want to change default.pa than daemon.conf. > I don't think the second point is for little gain. Sure, just reloading > the configuration on SIGHUP (or whatever mechanism) isn't that > interesting in itself, but runtime-changeable configuration is required > anyway in order to support configuration GUIs. Well, the simpler solution of just restarting PA when you click "apply", or possibly just give a warning message "Settings will not take affect until PA is restarted" is not to be forgotten. > I considered adding a > client API for writing configuration options to the project idea too, > but there seemed to be enough stuff in the idea already, and having such > an API has some problems (mentioned in this[1] message) for which we > would need to agree on a solution first. > > Originally, I also had another use case in mind: on Harmattan, > applications could install configuration files for a PulseAudio policy > module, and during installation PulseAudio's configuration had to be > reloaded. Since there was no support for doing that at runtime, each > application was expected to restart PulseAudio in their postinst script, > which was obviously not optimal (there could be music playing in the > background, for example). Thinking this a bit more, this probably isn't > a very relevant use case. Harmattan is dead, and we don't have other > examples where random applications would install configuration files for > PulseAudio. When PulseAudio itself is updated, the configuration may > change, but in that case it's better to restart PulseAudio anyway, since > the code has probably changed too. It would be nice to have a "deferred > restart" functionality that would restart the daemon once it becomes > idle, to avoid interrupting active streams, but that's a separate > discussion. > > [1] http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/16053/focus=16109 > >> If we go with this, I think we should make it a whitelist rather than a >> blacklist; i e, figure out a few parameters which are both useful to >> change at runtime and don't have implications all over the system. > > Yes, that's how I envisioned it to work. > >> Also, why SIGHUP? A native protocol extension seems more intuitive to me. > > AFAIK, SIGHUP is sort of standard for telling daemons to reload their > configuration. Hmm, googling on that, it seems to be used in a few other daemons, but it seems to be an adhoc standard rather than something formalised. > But thinking this a bit more, I agree that having this in > the client API would be better, because I think pactl should have > support for this, and it would be very confusing if pactl would send the > signal to the local server if it's otherwise configured to use a remote > server. Supporting SIGHUP still as an alternative should be pretty > trivial, though. Ok. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
