[PATCH weston 5/6] Pass config file from compositor to everything

Pekka Paalanen ppaalanen at gmail.com
Wed Mar 25 00:38:15 PDT 2015


On Tue, 24 Mar 2015 15:23:31 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi,
> 
> On 24 March 2015 at 13:56, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > We have the Weston command line option '--no-config' which is meant to
> > prevent loading weston.ini at all. It works for Weston itself, but it
> > does not work for any clients that also want to read weston.ini.
> >
> > To fix that, introduce a new environment variable WESTON_CONFIG_FILE.
> > Weston will set it to the absolute path of the config file it loads.
> > Clients will load the config file pointed to by WESTON_CONFIG_FILE. If
> > the environment variable is set but empty, no config file will be
> > loaded. If the variable is unset, things fall back to the default
> > "weston.ini".
> >
> > Note, that Weston will only set WESTON_CONFIG_FILE, it never reads it.
> > The ability to specify a custom config file to load will be another patch.
> >
> > All programs that loaded "weston.ini" are modified to honour
> > WESTON_CONFIG_FILE.
> 
> Would be a bit more work, but perhaps more flexible (i.e. can build
> in-memory if required) to pass a fd instead of a filename.

Hmm, I wonder how that'd work. Weston needs to export the config file
to all processes it spawns, including weston-desktop-shell.
Weston-desktop-shell has launchers spawning e.g. weston-terminal which
uses weston.ini, so it needs to relay too. And then if you manually
launch a weston-terminal from a command line, we'd need it to work
still.

The benefit would be building the config in-memory, right? But to get
an fd for a piece of memory, we usually just open a tmpfile. Sure,
there is memfd, but... hm.

The downside is that all processes that may need to export the config
would need to keep the file open at all times, so that the fd could be
inherited by children over exec. In normal production use, the config
file would be a normal file and we would have the fd overhead always.
Via launchers and weston-terminal's shell, the fd would be inherited by
every single process.

I'm not sure I see the benefit greater than the cost here.


Thanks,
pq


More information about the wayland-devel mailing list