Subject: Re: new kpi proposal, sysdisk(9)
To: Bill Studenmund <>
From: Elad Efrat <>
List: tech-kern
Date: 12/31/2006 22:34:46
Bill Studenmund wrote:

>> do we prefer to add a variable to 'struct vnode', something like I
>> showed in this message:
>> 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:

> 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).