--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 31, 2006 at 01:26:13PM +0200, Elad Efrat wrote:
> Bill Studenmund wrote:
>=20
> > 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=
e=20
> > outcome of this discussion, but what you're describing above strikes me=
 as=20
> > a great basis for deciding if "command bypass" ioctls should be blocked=
. I=20
> > personally am much more likely to trust a driver to get the partition=
=20
> > bounds checking code right as opposed to getting every nuance of=20
> > pass-through ioctls right.
>=20
> 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:
>=20
> http://mail-index.netbsd.org/tech-kern/2006/12/29/0033.html
>=20
> 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=
=20
opening a partition (or wedge) vnode, but we want the count for the whole=
=20
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=
=20
anything other than EPASSTHROUGH, we return that value.

(2) We define an ioctl that returns the address of the struct disk for the=
=20
device. Callers ask the driver for its struct disk then they operate on=20
it directly.

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

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

Take care,

Bill



--y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFl/bNWz+3JHUci9cRApQkAJ9CmA9WX/5kRoQaT5mn98yT8ntFLQCfQ9Nb
R8F6+5qFHCa/89z9DUCAA8w=
=zwx0
-----END PGP SIGNATURE-----

--y0ulUmNC+osPPQO6--