Re: [PATCH 03/14] drm: Link directly from drm_master to drm_device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 15 June 2016 at 16:45, Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxx>
>>
>> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux