[Intel-gfx] [PATCH 03/14] drm: Link directly from drm_master to drm_device
Emil Velikov
emil.l.velikov at gmail.com
Thu Jun 16 20:04:06 UTC 2016
On 15 June 2016 at 16:45, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, Jun 15, 2016 at 01:50:02PM +0100, Emil Velikov wrote:
>> On 14 June 2016 at 19:50, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
>> > Master-based auth only exists for the legacy/primary drm_minor, hence
>> > there can only be one per device. The goal here is to untangle the
>> > epic dereference games of minor->master and master->minor which is
>> > just massively confusing.
>> >
>> Good riddance :-)
>> Reviewed-by: Emil Velikov <emil.l.velikov at gmail.com>
>>
>> Taking this a step further, have you considered:
>> - having the master under drm_device, then
>> - nuking the drm_file/drm_minor one and adding drm_minor::has_master.
>> The last one will be checked before accessing drm_minor::dev::master.
>>
>> The above should work just fine, right ?
>
> We still need a pointer for the dev->master link. A later patch will
> simplify that, but entirely embedding doesn't work: drm_master must be
> free-standing, since when you drop_master all the clients authenticated
> against you will still be connected to your master. This is to make sure
> that they loose their authentication when vt switching to another X
> server. When you reacquire master with set_master, all the clients
> authenticated against that master are again considered authenticated.
>
Just to double check:
+ * Note that master structures are only relevant for the legacy/primary device
+ * nodes, hence there can only be one per device, not one per drm_minor.
In the above does "one per device" reference the "legacy/primary
device node" or the "drm_master struct" ? I was thinking about the
latter then again, reading your reply I'm not sure any more :-(
Or perhaps it is the latter but it should read "one active/associated
per device" ? In which case, yes drm_master should be standalone. Can
you please shed some light ?
Thanks
Emil
More information about the Intel-gfx
mailing list