Subject: Re: new kpi proposal, sysdisk(9)
To: Elad Efrat <elad@NetBSD.org>
From: Bill Studenmund <email@example.com>
Date: 12/31/2006 09:43:41
Content-Type: text/plain; charset=us-ascii
On Sun, Dec 31, 2006 at 01:26:13PM +0200, Elad Efrat wrote:
> Bill Studenmund wrote:
> > One other use for this, though, comes to my mind. It involves the=20
> > raw-access ioctl discussions we had. Unfortunately I do not remember th=
> > outcome of this discussion, but what you're describing above strikes me=
> > a great basis for deciding if "command bypass" ioctls should be blocked=
> > personally am much more likely to trust a driver to get the partition=
> > bounds checking code right as opposed to getting every nuance of=20
> > pass-through ioctls right.
> okay, so this becomes an implementation question.
And thank you for being patient with me in this thread. :-)
> 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=20
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=20
wasting space in all the other vnodes (since we'd have to have space in=20
the struct they all share). Even if we added the count only to device=20
vnodes, we waste space.
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=20
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=20
I tend to like idea (1) as it encourages all of the processing in one=20
routine we write. (2) encourages disparate parts of the kernel to start=20
knowing about struct disk internals. (1) seems less prone to future=20
Oh, and it should be easy for drivers to get right and for us to audit in=
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----