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
At first glance these seem like edge-cases that almost never happen. However I've seen these happen in practice with connectors, especially with docks.
One solution would be to number minor numbers like PIDs: don't recycle card0 before we've reached the upper minor number limit.