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? 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. 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. 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. -- Tanu
