Re: [gdm-list] [PATCH] fix race condition when setting the model for the face browser

[Brian Cameron <Brian Cameron Sun COM>]

Ludwig:

[Discussing the crummy way GDM passes face image data/information
between GUI and daemon]

> > I would not be opposed to changing the way this works.  It would
> > probably be nicer if the GDM daemon looked around for face images
> > and copied them to someplace in /var/tmp where the greeters could
> > find them so we don't keep trying to access users $HOME directories
> > every time a new GUI displays.  On multihead systems (or terminal
> > server type environments) I'm sure the current logic works very
> > poorly.
>
> Does the face browser really need to be optimized for that use case?
> If there are too many users the face browser isn't of much use
> anyways. KDM on SUSE for example displays up to seven users. If
> there are more users in the system it displays the seven most
> recently logged in ones instead.

No, I'm just trying to think of ways that the daemon could "set up"
a directory with the information for the greeters without needing
to pass the information (e.g. image data) over any protocol.

> > Could you explain in more detail how the messages pass back and
> > forth to support the Face Browser?
>
> Well, you are the maintainer of GDM. Don't ask me how or why it
> works the way it works :-)

This section of the code was written by the previous maintainer,
so I'm probably not that much more familiar with it than you.  I
do know that GDM supports a few different mechanisms for communicating
between the client and server (e.g. FIFO, SUP, and SOP protocols
as mentioned in the daemon/gdm.h file).  Perhaps GDM already has
another protocol mechanism that would be more appropriate for
passing the face browser data?

> > Could we think of a different way to make this work that would
> > avoid the problem?  Is there really a need for the GUI to talk to
> > the daemon to display the Face Browser?
>
> That's what I am wondering too.
>
> > Why can't the daemon just set up some data in a directory like
> > /var/tmp/gdm/facebrowser so that when the GUI starts up it can
> > just read some configuration files there (and image files) and set
> > itself up properly without having to talk to the daemon at all?
>
> You'd have to maintain that cache directory somehow so that if a
> user changes the image the cache gets udpated as well. 

This isn't really that much more than what GDM already does.  It
already regrabs the image from the user's $HOME directory every
time a GUI is displayed.  Is re-updating a cache every time the
GUI is displayed any worse?

> That's
> overkill for little gain. IMHO custom images are just a gimmick for
> home users which means low number of users and local home
> directories. So the most simple way to read the images is to just
> access the file in the home directory directly as user gdm. If gdm
> is not allowed to access the file then so it be.

The problem with making this sort of change is that GDM may seem to
break for users if we change this behavior.  You will have to talk
me into making a change that will generate a log of bug reports
asking why things stopped working.  Can't we think of a way to fix
this that would be less likely to break current behavior?

Also there may be reasons we're not thinking about why it makes
sense for the daemon to poke for these image files rather than the
GDM user.  I've reviewed the GDM ChangeLog and docs, but don't see
any real explination why it works this way.  Thoughts?

Brian