Bill Studenmund wrote:

>> do we prefer to add a variable to 'struct vnode', something like I
>> showed in this message:
>>
>> http://mail-index.netbsd.org/tech-kern/2006/12/29/0033.html
>>
>> or the sysdisk(9) interface, perhaps with some modifications/additions?
> 
> I prefer the latter for two reasons. 1) It gives us a fairly stable 
> iterface, so we can change the implementation details as we wish.
> 
> 2) I'm not sure if the vnode option will work. The problem is that we are 
> opening a partition (or wedge) vnode, but we want the count for the whole 
> disk. We could keep the count in the whole-disk vnode, but then we'd be 
> wasting space in all the other vnodes (since we'd have to have space in 
> the struct they all share). Even if we added the count only to device 
> vnodes, we waste space.

alright, so I'll go on with the diff I posted, perhaps with an
additional parameter (const char *) and/or similar set of routines that
take a dev_t.

> I think we need to take a page from the tty subsystem. A lot of routines
> in tty drivers are just calls to tty subsystem routines after the driver 
> verifies the minor number and gets the struct tty.
> 
> I see two ways to handle it here. (1) define a disk_ioctl() routine to
> which you pass the struct disk & all other ioctl parameters. If it returns 
> anything other than EPASSTHROUGH, we return that value.
> 
> (2) We define an ioctl that returns the address of the struct disk for the 
> device. Callers ask the driver for its struct disk then they operate on 
> it directly.
> 
> I tend to like idea (1) as it encourages all of the processing in one 
> routine we write. (2) encourages disparate parts of the kernel to start 
> knowing about struct disk internals. (1) seems less prone to future 
> problem. :-)

unless I misunderstood, we are already doing #1:

http://opengrok.netbsd.org/source/xref/sys/kern/subr_disk.c#432

> Oh, and it should be easy for drivers to get right and for us to audit in 
> contributed drivers.

indeed, that's the goal of sysdisk(9).

-e.