[PATCH] Introduce weston-launch

[Pekka Paalanen]

On Wed, 1 Feb 2012 15:37:11 +0100
Benjamin Franzke <benjaminfranzke at googlemail.com> wrote:

> 2012/2/1 Tiago Vignatti <tiago.vignatti at linux.intel.com>:
...
> >
> > On 01/31/2012 09:22 PM, Benjamin Franzke wrote:
> >>
> >> weston-launch starts weston and provides mechanism
> >> for weston to set/drop drm master, open a tty,
> >> and read input devices without being root.
> >>
> >> Execution is allowed for local-active sessions
> >> or users in the group weston-launch.
> >
> >
...
> >> diff --git a/configure.ac b/configure.ac
> >> index 62d36eb..d5d8313 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -139,6 +139,22 @@ if test x$enable_clients == xyes; then
> >>
> >>  fi
> >>
> >> +AC_ARG_ENABLE(weston-launch, [  --enable-weston-launch],,
> >> enable_weston_launch=yes)
> >> +AM_CONDITIONAL(BUILD_WESTON_LAUNCH, test x$enable_weston_launch == xyes)
> >> +if test x$enable_weston_launch == xyes; then
> >> +  PKG_CHECK_MODULES(WESTON_LAUNCH, [libdrm])
> >> +  PKG_CHECK_MODULES(SYSTEMD_LOGIN, [libsystemd-login],
> >> +                   [have_systemd_login=yes], [have_systemd_login=no])
> >> +  AS_IF([test "x$have_systemd_login" = "xyes"],
> >> +       [AC_DEFINE([HAVE_SYSTEMD_LOGIN], [1], [Have systemd-login])])
> >> +
> >> +  AC_CHECK_LIB([pam_misc], [pam_open_session], [have_pam=yes],
> >> [have_pam=no])
> >> +  if test x$have_pam == xno; then
> >> +    AC_ERROR([weston-launch requires pam])
> >> +  fi
> >> +  WESTON_LAUNCH_LIBS="$WESTON_LAUNCH_LIBS -lpam_misc"
> >> +fi
> >> +
> >
> >
> > another thing is the dependency chain we're creating. I already dislike the
> > fact that I'm not able to start weston without desktop shell and now we
> > would be adding one more program. Debugging cries. I haven't though much,
> > but can we have a disjoint solution instead?
> 
> You mean to start weston and weston-launch (the permission part) seperately?
> We could do that, but thats of course not that handy, and would
> produce two problems:
>  - The tty would need to be chowned to the user
>  - The control socket couldn't be passed through fork.
>    (a unix socket wouldnt suffice since other applications could use
> that as well)
> 
> So that would really be a debugging-only solution.
> Instead we can just keep the possibility to start weston without
> weston-launch, as its done now.
> 
> And for debugging weston with weston-launch there is the sleep option,
> so you can start weston-launch,
> and attach to weston using gdb --pid.

Ah, that's a solution I didn't think of. We might need something for
debugging desktop-shell client, too. All I could think of so far is to
modify the exec() call to start it in gdb instead of directly.

Passing an open fd through fork() and exec() is very simple and handy,
but ruins debugging possibilities, if the client crashes at startup.
Would be nice to figure out a generic solution for this.


Thanks,
pq