Greetings everyone, Above all - hell yeah. Thank you Tvrtko, this has been annoying the hell out of me for ages. On Tue, 14 Mar 2023 at 14:19, Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > > From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > With the typical model where the display server opends the file descriptor > and then hands it over to the client we were showing stale data in > debugfs. s/opends/opens/ But as a whole the sentence is fairly misleading. Story time: The traditional model, the server was the orchestrator managing the primary device node. From the fd, to the master status and authentication. But looking at the fd alone, this has varied across the years. IIRC in the DRI1 days, Xorg (libdrm really) would have a list of open fd(s) and reuse those whenever needed, DRI2 the client was responsible for open() themselves and with DRI3 the fd was passed to the client. Around the inception of DRI3 and systemd-logind, the latter became another possible orchestrator. Whereby Xorg and Wayland compositors could ask it for the fd. For various reasons (hysterical and genuine ones) Xorg has a fallback path going the open(), whereas Wayland compositors are moving to solely relying on logind... some never had fallback even. Over the past few years, more projects have emerged which provide functionality similar (be that on API level, Dbus, or otherwise) to systemd-logind. Apart from that, the commit is spot on. I like the use of rcu and the was_master handling is correct. With some message polish this commit is: Reviewed-by: Emil Velikov <emil.l.velikov@xxxxxxxxx> I also had a brief look at 01/10, although I cannot find many references for the pid <> tguid mappings. Be that on the kernel side or userspace - do you have any links that I can educate myself? Thanks Emil
