Re: kcmp(2)

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Wed, 19 Jul 2023 03:51:29 +0000
> From: David Holland <dholland-tech%netbsd.org@localhost>
> 
> 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.