Subject: Re: new kpi proposal, sysdisk(9)
To: Bill Studenmund <firstname.lastname@example.org>
From: Elad Efrat <elad@NetBSD.org>
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).