On Wed, 5 Jul 2000, Jason R Thorpe wrote:

Before I begin, I want to say that I like where you're trying to go with
this. I have concerns about how how this would get us there, but I like
the destination!

> Essentially, for all the routines that take a `dev_t' argument now, I
> want to change them to take a `struct vnode *' instead.  specinfo will
> be augmented to include an opaque cookie (void *si_devcookie) which will
> be available as `vp->v_devcookie' similar to how `vp->v_rdev' is available.

I do see that we have a problem that we need to be able to configure these
devices without having one around - you need to be able to go from 0 vnds
or ccds or raids or vgs to one yet if the driver does it, you have to be
able to open a device which hasn't been configured.

What would this win us over doing something like creating a new character
device which controls the configuration of these clonable devices? Each of
the on-the-fly devices registers at kernel init. This device then takes
ioctls which grow or shrink the number of configured devices. So you could
do an ioctl which would tell the system to configure 64 "pty"'s. Or add a
"vg". Or destroy a particular cloning device (like vg0 when we have 3 of
them). ??

> Instead of the dev_t argument, device open routines will get the device
> from vp->v_rdev, and take appropriate action.  For devices like a regular
> disk, it would be something like:

> This would then allow something like the ccd, raid, or vnd devices
> to allocate the softc structure in the ioctl routine when the device
> is actually configured, and free the softc when the device is
> de-configured.

Given that you have to be able to do ioctl's on ccd, raid, vnd, or vg
devices when you might not have a softc defined, wouldn't it be simpler to
leave things as they are, and just change these devices to live (in a
degraded mode) with no softc around? They are the only ones which need
this ability. :-)

i.e. let the open routine in these drivers always succeed, even for
unconfigured devices. Then keep the checks to see if there is a softc
around (like the nice one I cut out above) in all of the driver's
routines. For everything other than ioctl or close, no softc == exit with
error. close would succeed, and ioctl would only let you configure the
device.

> The drawback is that it (obviously) requires a lot of changes to various
> parts of the kernel... although I think many of them can be done
> incrementally.
> 
> Anway, this is just a rough sketch of the idea right now... any comments?

Agreed. If we need it, then we need it. But what about the above?

Also, it makes us quite different from other BSD's. Porting drivers or
trying to maintain one driver source tree for multiple OS's would become
more complicated. While I know you and a number of us could deal with the
complexity, I'd rather not add it if we don't have to. I'd like to get
lots of folks into making drivers, and the easier it is to port them
(within reason), the better.

Take care,

Bill