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