> Date: Wed, 19 Jul 2023 03:51:29 +0000 > From: David Holland <dholland-t...@netbsd.org> > > On Tue, Jul 18, 2023 at 03:25:02PM -0700, Jason Thorpe wrote: > > That *might* work in this particular case, but it would not work > > for e.g. a cloning device where you get additional descriptors via > > dup() or whatever. > > Don't cloner instances differ in minor number? If not, shouldn't they?
Cloning devices can return whatever they want in struct stat -- they have full control over the .fo_stat operation. In this case, the drm device nodes (/dev/dri/cardN, /dev/dri/renderN) have a .fo_stat function that returns the same dev_t as exists on disk in st_dev, and returns 0 in st_ino, with an XXX comment next to the st_ino setting to indicate it's not clearly the right thing. If you open /dev/dri/cardN twice, you'll get two independent instances of kernel state (struct drm_file), with, for example, independent mmappable address spaces of graphics buffers, and independent vblank event queues. But on the back end, they will represent access to the same Nth drm device on the system. And, separately, on the front end, they will expose the same (st_dev, st_ino) pair. It's still not clear to me exactly what notion of equivalence Mesa needs to discern here (same underlying hardware device? same instance of kernel state? same device node interface? same physical file representing the device node?), or why. For example, if it's a matter of avoiding repeating some kind of GPU initialization, well, there's already a mechanism in the kernel for doing that (firstopen/lastclose). So I'm still fuzzy on the consequences of either having or not having this interface. Without a coherent picture of what it's there for, I'm inclined to think we should try to make do without it rather than stumble around trying to mimic incoherent semantics.
