On Wed, Jul 05, 2000 at 06:12:20PM -0700, Bill Studenmund wrote:

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

Oh, this is simple.  Let's just take the example of ccd:

int
ccdopen(struct vnode *vp, int flags, int fmt, struct proc *p)
{
	struct ccd_softc *cs;
	struct disklabel *lp;
	int error = 0, part, pmask;

	cs = ccd_lookup(DISKUNIT(vp->v_rdev));
	if (cs == NULL) {
		if (part == RAW_PART) {
			/*
			 * Device will be created and marked open
			 * in ccdioctl() later.
			 */
			return (0);
		}
		return (ENXIO);
	}

	/* body of function */

	vp->v_devcookie = cs;
	return (0);
}

...

int ccdioctl(struct vnode *vp, u_long cmd, caddr_t data, int flag,
    struct proc *p)
{
	...

	case CCDIOCSET:
		if (cs != NULL) {
			error = EBUSY;
			goto out;
		}

		/* Create the device. */
		cs = malloc(sizeof(*cs), M_DEVBUF, M_WAITOK);
		...

		/* Creation was successful! */
		vp->v_devcookie = cs;
		return (0);

	...
}

...etc :-)

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

Let's ignore things like ptys for now ... they're a different animal :-)

The advantage my scheme has for e.g. CCDs is that you need to issue an
ioctl to configure them anyway, and there are flags to see if the device
is initted in the CCD driver.  This merely uses the semi-cloning mechanism
to get dynamic creation and to check for "initialized" :-)

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

I guess we were sort of on the same wavelength here.

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

We already have better technology inside than the other BSDs :-), so this
isn't really much of an issue, as far as I'm concerned.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>