On Thu, Aug 4, 2022 at 10:02 AM Mark Wielaard <m...@klomp.org> wrote:
> I wonder if we should generalize that for other DEBUGINFOD_envs. But > instead of adding more environment variables have a debuginfod control > file like we already have for cache_clean_interval, max_unused_age and > cache_miss. > > So as an alternative to setting any of the DEBUGINFOD_frob environment > variables you could put an urls, cache_path, progress, verbose > retry_limit, timeout, maxtime, maxsize or headers file under > XDG_CONFIG_HOME (~/.config) debuginfod_client that would be used if the > corresponding environment variable isn't set. > > The downside of course is that it would cause more file stats when > creating a debuginfod_client handle, but the overhead is probably > minimal especially if programs just reuse the debuginfod_client > objects. > > Or maybe it should just be one control file that can have entries for > all of the variables. > Generalizing our use case, configuration files help when you're looking to put permissions on part of the debuginfod configuration. Not sure if that generalizes beyond supplying headers, but maybe in the future? I could also see file-based config being useful if some aspect of the debuginfod configuration can change from moment-to-moment. Environment variables could be used for that, but it would require either changing those variables in the calling shell or wrapping each debuginfod client utility. Or maybe just if the number of environment variables grows unwieldy. For the permissions and mutable configuration cases, it would be desirable to point debuginfod at different paths, so that these could be kept in e.g. tmpfs. These might be machine generated, which also means there may be multiple sources of such files. So, something like a DEBUGINFOD_CONFIG_FILES list might work well there; each file could contain, say, a list of environment_variable=value pairs, (or a more debuginfod-specific format), and all the files in the list could be concatenated together. Then, a service set up in bashrc could append or prepend its moment-to-moment configuration runfile to the list of config files. You could also do this more granularly: DEBUGINFOD_HEADERS_FILES would work for us, and other lists could be created for other dynamically controllable aspects of the system. This wouldn't compose as well if you needed to do hackery to say, remove a source of config from the list, though, as then you'd have to find and remove n sources of config from n lists. -- Daniel Thornburgh | dth...@google.com
