[PATCH 1/2] drm: Make control nodes master-less

[David Herrmann]

Hi

> You didn't miss any patches. It was I who missed the usage in drm_crtc.c.
> I guess this, and Daniel's reply prompts a discussion about control
> nodes and the master concept.
>
> First I'd like to give some background about the use-case: I'd like to
> use the control node for a daemon that tells the vmwgfx driver about the
> host GUI layout of the screen: What connectors are enabled, the
> preferred mode of each output and some driver private information. The
> daemon will run as root and only a single instance per device. Trying to
> do this as-is will cause the vmwgfx driver to BUG() because it currently
> assumes one active master per device. Not one active master per minor
> (although that could be changed if needed).

Why do you tie this to DRM-Master? Can't you just limit these special
ioctls to the control-node and drop any master-requirements? This way
you don't care whether the FD on the control-node is master or not,
you just assume that access-rights on the control-node are highly
restricted so anyone opening it is privileged to issue these ioctls.

> Looking at
>
> http://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/
>
> it doesn't really make sense to keep the master concept on the control
> node, but it perhaps makes sense to keep it on future modesetting nodes
> to allow multiple modesetters to open the same device node?
>
> In that case all master access in drm_crtc.c would be changed for now to
> be conditioned on file_priv->minor->type == DRM_MINOR_LEGACY

The Master-concept only really makes sense for operations affecting
global state. On non-legacy drivers this is basically KMS. Therefore,
I see no reason to extend the master-concept to non-modeset/primary
nodes. So ACK on changing drm_crtc.c to check for master only if
minor==DRM_MINOR_PRIMARY/LEGACY (there are pending patches renaming
it..).

The problem with the modeset-node concept described in my blog-post is
KMS-object hotplugging. We don't support it.. and I don't see any
proper way to extend our API in a suitable way. The only thing I still
have planned is to allow creating multiple DRM_MINOR_PRIMARY/LEGACY
nodes and splitting mode-objects among them. We would have to do that
before anyone uses the device to prevent objects from disappearing,
but this could easily be done as udev-action. Thus, setting up
multiple KMS interfaces on a single card.

Anyhow, imho we should just try to remove any master-handling from any
core DRM code. Ideally, only drm_drv.c deals with DRM-Master when
checking for permissions. Everything else should never attach any
information to these things. Especially the master-related driver
callbacks are undocumented and really weird. If we'd be able to drop
all this, I think we can start looking forward.

Thanks
David