Question about ARC and GDM

Brian Cameron Brian.Cameron at sun.com
Wed Feb 27 23:00:14 PST 2008


LSARC:

As some of you may be aware, the GDM display manager is undergoing a
rewrite.

   http://live.gnome.org/GDM/NewDesign

In many regards, this rewrite is long-overdue.  The design of GDM has
not changed significantly in over 5 years, and the new rewrite is
making use of newer and better design, such as GObjects and D-Bus for
inter-process communication.  There are also plans afoot to make GDM
better integrate with GNOME overall, in terms of theming and
look-and-feel.  Other benefits are detailed at the above link.

On the downside, the configuration system of this new GDM is being
reworked.  While it is too early to tell exactly what the impact will
be, I anticipate that the configuration mechanisms will be incompatible
with the current GDM.  I believe this is an issue we need to think about
because GDM's current configuration mechanisms were declared as Stable
(Committed) in LSARC 2005/734.  At the time of LSARC 2005/734, there was
no visibility that the configuration would ever change, and the decision
to make them Stable seemed sensible at the time since login
configuration isn't the sort of thing that we want users to rework
unless necessary.

That said, breaking GDM's configuration stability might not be so
serious.  I say this because GDM has never been the default login
program on Solaris.  It has primarily been available for users with
accessibility needs, so they can have a workable alternative they can
switch to.  Though it is also used by some people who simply like GDM
over CDE login.  Since GDM is not the default login program, any
interface breakage will likely not impact a great number of users.
Also, the interfaces have only been declared as Stable/Committed in
Nevada (not in Solaris 10), so there has not yet been a supported
Solaris release that contains these interfaces marked as Committed.
Though, the upcoming Indiana release may change that (though I'm not
sure whether Indiana carries the same interface stability requirements
as, say, Solaris 10).

The new GDM rewrite will not be released until GDM 2.24 at the
earliest, and (probably more realistically) won't be ready for use
on Solaris until GDM 2.26.  Since GDM 2.24 won't be released for about
7 months, and 2.26 for about 13 months, that gives us some time to
figure out the best way to deal with these interface changes.

I can imagine a few options we can consider (or perhaps a combination
of them):

+ We could EOF/EOL the existing GDM configuration interfaces, so that
   we can replace it with the new GDM in a year's time.  As I state
   above, this fits in well with the expected time it will be ready
   for use on Solaris.

+ We could ensure that there is configuration migration from the
   old GDM to the new GDM.  I am pretty sure that there will not be
   a 1-to-1 mapping of configuration options, so it is unlikely that
   all user configuration would migrate, but we could likely make sure
   that the most important (e.g. security related) options do migrate.

+ We could continue shipping the existing GDM 2.20 and also ship
   the new GDM in parallel, allowing the user to pick which one they
   want to use.

+ Other ideas?

I know that the CDE is in the process of being EOL/EOF (LSARC 2007/648),
but I think we should hold-off on removing CDE login as the default
login program until the new GDM rewrite is ready to replace it.  Since
it will likely be some time before Sparc is ported to Xorg, I do not
think it would be possible to switch to using GDM as the default login
program in the near term anyway.  Note that for GDM to be the default
login program, we have to use Xorg since it supports VT (Virtual
Terminal) switching while Xsun does not.  This is required to allow
users to switch to "console login".  Obviously, this should not impact
the EOL/EOF of the other CDE components.

I am interested to hear what ARC thinks the best approach should be.
I wanted to raise this issue early so that we could consider the
EOF/EOL process if that is most appropriate.

Thanks,

Brian



More information about the opensolaris-arc mailing list