On Fri, May 22, 2020 at 12:54:32PM +0300, Pekka Paalanen wrote:
On Wed, 20 May 2020 16:19:00 +0200 Daniel Vetter daniel@ffwll.ch wrote:
On Wed, May 20, 2020 at 3:20 PM Simon Ser contact@emersion.fr wrote:
On Wednesday, May 20, 2020 2:55 PM, Daniel Vetter daniel@ffwll.ch wrote:
Maybe we should add an explicit note that there's no guarantee about the new chardev minor this new device will get, it could both inherit the existing one (you can't open the old one anymore anyway) or get a new one?
Or does userspace want a guarantee, i.e. as long as there's still a handle open kernel guarantees to not recycle the chardev minor (which is what we currently do). In that case better to add that to your list of guarantees above.
The are race conditions to consider too, e.g.
- Compositor sends /dev/dri/card0 to a client
- card0 goes away
- Another device takes card0
- Client receives /dev/dri/card0 and then starts using it, but it's the wrong device
Oh reminds me, what should we do about open() - that one will fail, the chardev is going away after all, not failing kinda doesn't make sense. And more tricky, about creating new leases?
I think reasonable semantics here would be that both of these "create a new open drm fd" operations can fail as soon as the device is unplugged. Userspace needs to be able to deal with that.
Hi,
yeah, we can make mmap read/write end result undefined, recycle char minors like pids, and let new open()s and new leases fail. Pretty much everything Daniel and Simon said make sense to me.
I'll spin a v2, but maybe next week.
What about the drm_ioctl() issue Andrey pointed out?
Dropped some thoughts there, tbh dunno, need some more discussions? -Daniel