<div dir="ltr">HI Pekka,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 26, 2017 at 2:06 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 24 Oct 2017 08:26:04 -0500<br>
<div><div class="h5">Matt Hoosier <<a href="mailto:matt.hoosier@gmail.com">matt.hoosier@gmail.com</a>> wrote:<br>
<br>
> On Tue, Oct 24, 2017 at 1:33 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br>
> > On Mon, 23 Oct 2017 14:37:37 -0500<br>
> > Matt Hoosier <<a href="mailto:matt.hoosier@gmail.com">matt.hoosier@gmail.com</a>> wrote:<br>
> ><br>
> >> It would be nice for non-session uses of Weston (embedded systems) if<br>
> >> the controlling TTY didn't need to be manually supplied.<br>
> >><br>
> >> Has anybody suggested using something like VT_OPENQRY in the<br>
> >> weston-launcher code to pick a TTY if one wasn't manually given? (Or<br>
> >> if that's too auto-magic for taste here, then only do that if a<br>
> >> specific command-line option is supplied.)<br>
> ><br>
> > Hi,<br>
> ><br>
> > I do not recall such proposals. I'd like to hear more about your use<br>
> > case.<br>
> ><br>
> > Do you mean in 'weston-launch' specifically, or in all the launcher<br>
> > implementations?<br>
><br>
> Sorry for the imprecise wording. I'm not thinking of a adding a duty that's<br>
> specifically carried out by the weston-launch executable. My suggestion<br>
> would be to add the logic somewhere in with the code in launcher-direct.c<br>
> that gets executed directly in-process when Weston is invoked something<br>
> like 'weston --tty=2 --backend=drm-backend.so ...'.<br>
><br>
> I think that the call graph in mind would be something like:<br>
><br>
>   compositor-drm.c:      drm_backend_create()<br>
>   launcher-util.c:         weston_launcher_connect()<br>
>   launcher-direct.c:         launcher_direct_connect()<br>
>   launcher-direct.c:           setup_tty()<br>
<br>
</div></div>Ah, so the launcher direct path only, which means you run weston and<br>
all its clients as root. Weston does spawn some clients of its own<br>
automatically, depending on configuration. None of them are written to<br>
be safe to run as root.<br></blockquote><div><br></div><div>That's understood. And while I admit to being presently guilty of running Weston as root in this style, it's not difficult at all to use system's 'User=' directive to change that. As far as I can tell though, choosing to execute as some non-zero UID is a separate question than TTY management though.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> > If for 'weston-launch' specifically, then I'd like to ask why you want<br>
> > that instead of a logind service?<br>
> ><br>
> > I've been hoping there would be no need for new development on<br>
> > weston-launch. It is sensitive code, being setuid root. It seems it<br>
> > cannot be nicely generalized to support all libweston-based compositors.<br>
><br>
> I'm uncertain whether the code impacted in launcher-direct.c actually gets<br>
> exercised too by some indirect path in weston-launch. Maybe you know the<br>
> answer to that?<br>
<br>
</span>No, it does not. launcher-direct.c is purely for running weston as<br>
root, without any helpers like logind or weston-launch.<br>
<span class=""><br>
> ><br>
> > What is the launching context in you use case? E.g.<br>
> > - manual login, type 'weston' in VT<br>
> > - type 'weston -Bdrm-backend.so' in a terminal window<br>
> > - launching weston from a systemd system unit<br>
> > - launching weston from a systemd user unit<br>
> > - something else?<br>
><br>
> The case I'd like to improve is launching weston from a systemd system<br>
> unit. Currently that involves either hacking the systemd unit with a<br>
> manually chosen TTYPath= directive, or else baking in a command-line option<br>
> like --tty=3 to Weston. Those both feel forced and (in my opinion) require<br>
> building in an unnecessary amount of product-specific knowledge into the<br>
> systemd unit; there's no reason I can see that Weston should really care<br>
> what VT is used.<br>
><br>
> Maybe I'm not recognizing some reason why it's advantageous for Weston to<br>
> have an explicitly chosen VT though?<br>
<br>
</span>You're right in that Weston shouldn't care, but I would expect the<br>
system designer or administrator to care, usually.<br></blockquote><div><br></div><div>I think that it would only typically be important if the designer has some use-case for actively hopping among more than one VT. That is, at least, not my case. Weston is the only DRM user -- it just needs some valid VT to use. I would be interested to hear counterexamples though. Are you thinking that some program like Plymouth would get used early during boot, and it would need to persist and occasionally show itself during the main body of the runtime?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If there actually is a need to runtime discover a free VT because there<br>
are also other units grabbing VTs, then would you not have a race<br>
causing everything to be launched on random VTs?<br></blockquote><div><br></div><div>In the spirit of my reply above, I don't think there are really other units to be worried about racing against.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You should be able to avoid the TTYPath hardcoding by using a systemd<br>
instantiated units (e.g. getty@.service) or template units. The<br>
instantiated approach will leave the TTY choice for the system<br>
administrator, but guarantee the same tty is always used once<br>
"configured".<br>
<br>
FWIW, running Weston directly as root is meant only for debugging. If<br>
you are using systemd units, I would very much recommend using the<br>
systemd PAM directives to run weston as non-root and relying on logind<br>
instead of launcher-direct.c. An alternative would be to arrange<br>
auto-login with a getty and launch weston from systemd user units along<br>
with all the other stuff you need, but it's not always as flexible as<br>
one might like.<br></blockquote><div><br></div><div>I had a look at the logind support code in Weston does. Unless I'm missing something, I think it's fair to summarize it as simply code that queries systemd to ask "what TTY has already been allocated for the cgroup in which my PID is a member?". If that's right, then I think taking this approach still tacitly agrees to the idea that a system designer has hand-picked a TTY (whether through a getty@.service default instance, a weston@<tty>.service default instance, or similar).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Btw. have you seen <a href="https://phabricator.freedesktop.org/T63" rel="noreferrer" target="_blank">https://phabricator.<wbr>freedesktop.org/T63</a> ?<br>
I think we could use a bunch of example systemd unit files in Weston<br>
upstream, but have had no time to work on that.<br>
<span class=""><br>
> > What is the "non-session" use exactly? Why do you not care which VT<br>
> > weston will occupy in that case?<br>
><br>
> This is another case where I was groping for a good term to use.<br>
> "Non-session" isn't quite right. What I meant was: the instance of Weston is<br>
><br>
> - Well known to systemd;<br>
> - Not the parent of the graphical clients (those are each managed from<br>
> their own systemd units); and<br>
> - Not a "session" in the sense of being a login initiated explicitly from a<br>
> VT in the way that GDM does.<br>
><br>
> The identity of the VT on which Weston binds doesn't really seem to matter<br>
> for an embedded device. There's no user sitting at the keyboard typing<br>
> Ctrl+Alt+F2 to multiplex among numerous sessions.<br>
<br>
</span>Ok, that makes sense.<br>
<span class=""><br>
> If any of the regular contributors here who work with embedded devices have<br>
> a different experience, I'd be interested to hear. But typically, I find<br>
> that every silicon manufacturer's delivery of Weston has a default systemd<br>
> unit that does one of the following:<br>
><br>
>   - uses TTYPath=<br>
>   - passes some arbitrary value to Weston with --tty=<br>
>   - wraps the entire Weston process with openvt(1)<br>
<br>
</span>Right. :-)<br>
<span class=""><br>
> > I haven't checked recently, but I have a feeling that Weston is not<br>
> > expecting to be spawned on a currently inactive VT, so that might need<br>
> > fixing as well.<br>
><br>
> I think this use-case actually works well already. If you open up an SSH<br>
> shell to an embedded device (hence, its controlling terminal is just a PTY<br>
> rather than a Linux VT) you can do:<br>
><br>
>     weston --tty=1; sleep 1 &<br>
>     weston --tty=2; sleep 1 &<br>
>     weston --tty=3; sleep 1<br>
>     ...<br>
><br>
> Each instance of Weston will manage to activate the VT it's been told to<br>
> use.<br>
<br>
</span>Indeed, you are right. Looks like all three launcher implementations<br>
make the switch.<br>
<span class=""><br>
> >> The closest I can find to a question about this topic prior on the<br>
> >> mailing list is<br>
> >><br>
> <a href="https://lists.freedesktop.org/archives/wayland-devel/2013-October/011472.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>archives/wayland-devel/2013-<wbr>October/011472.html</a><br>
> .<br>
> >> That change was never adopted, but it doesn't look like the use of<br>
> >> VT_OPENQRY has anything to do with Kristian's objections at the time.<br>
> ><br>
> > Picking the first free VT sounds fine to me, but do display servers<br>
> > actually do that on their own or does e.g. the graphical login manager<br>
> > do it for them? Or rather, when and who usually picks the VT?<br>
><br>
> I think that I get the point you're making about the graphical login<br>
> manager selecting the VT. I agree for desktop usage. The embedded cases I<br>
> keep seeing have no graphical login manager though. You might be likely to<br>
> respond that in this situation weston-launch should be the poor-man's<br>
> graphical login manager. I have some thoughts on why that's awkward when<br>
> crafting a systemd system unit -- we can maybe discuss that more if you're<br>
> inclined to pursue it.<br>
<br>
</span>No need. :-)<br>
<br>
weston-launch could indeed be the poor-man's login manager when you<br>
don't have systemd.<br>
<br>
I think that weston-launch should never be used in a systemd unit,<br>
system or user. You will have logind, it's better to rely on that<br>
instead. The poor-man's login manager is the systemd system unit<br>
written to launch weston as a specific user, which I believe will also<br>
set up the user session as a side effect.<br>
<br>
With logind, it seems the VT/tty is chosen before Weston starts and<br>
launcher-logind.c just ensures it's the same as what the user defined<br>
with --tty if any. I think that would make it not possible to let<br>
Weston pick the tty on logind - you do it in the unit file.<br>
<br>
After all the above, would you still want automatic allocation of a VT<br>
in any of the weston launcher implementations?<br>
<br>
<br>
Thanks,<br>
pq<br>
<br>
Ps. It might be interesting to make Weston work in a system where the<br>
kernel has CONFIG_VT=n. ;-)<br></blockquote><div><br></div><div>Making Weston operate with CONFIG_VT=n would indeed be interesting.</div><div><br></div><div>I think I'd just like to float the original question again: would anybody be receptive to a very limited patch that does nothing more than narrowly allow Weston to survive the TTY selection phase in the absence of any external hint such as --tty=, logind, or being spawned from a process whose stdin is already a VT?</div><div><br></div><div>If that seems contrary to the direction you'd like to take Weston, that's okay. It's not a huge burden to do explicit TTY selection at system-design time. That just seems a bit unnecessary for devices whose only raw DRM user is Weston.</div><div><br></div><div>-Matt</div></div><br></div></div>