Brian Cameron wrote:
>
> Alan:
>
>>> The attached change adds a patch to fix GDM so if it fails to run
>>> fbconsole, it will recover more gracefully. The forked child process
>>> should just exit in this case.
>>
>> Not this bug, but a related bug I haven't gotten around to filing yet:
>> I noticed this week when logging in & out repeatedly on OpenSolaris build
>> 99, that gdm starts a new fbconsole every time and never kills the old
>> ones, so after a while I had 20 fbconsoles running, when any more than
>> one is a waste of memory.
>
> Actually that bug has been fixed. It was the fix for that bug which
> introduced the problem I am fixing with this patch.
Cool, thanks.
> By the way, Alan, GDM currently assumes fbconsole is in
> /usr/openwin/bin. Should GDM be looking for fbconsole in a
> different directory since I'm assuming /usr/openwin/bin is
> not ideal for OpenSolaris?
>
> For backwards compatibility, should GDM try to find fbconsole
> in different directories in a certain order? Like first
> checking /usr/openwin/bin/fbconsole, and then checking
> /usr/X11/bin/fbconsole if it isn't in /usr/openwin/bin?
On nv_99 & later, fbconsole is delivered in /usr/X11/bin, with
a symlink in /usr/openwin/bin for backwards compatibility.
(In Nevada, the symlink is /usr/openwin/bin/fbconsole ->
/usr/X11/bin/fbconsole. In Indiana, it's covered by the
general /usr/openwin -> /usr/X11 symlink.)
For the gdm you deliver to current Nevada builds, just looking
in /usr/X11/bin should be enough. For upstream gdm, which
needs to work on Solaris 10 & older too, looking in multiple
locations, or just sticking with /usr/openwin/bin and using
the compatibility links, would be better.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
