In some email I received from Jason R Thorpe, sie wrote:
> Hi folks...
> 
> I'm needing to add support for cloning bdev/cdev devices soon, and
> also for another sort of semi-cloning device, similar to the network
> pseudo-device cloning stuff I did recently.  Both are going to require
> some sort of change to the devsw routines, and I think I've come up with
> one that will work for both.
> 
> 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.
> 
> 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:
> 
> int
> fooopen(struct vnode *vp, int oflags, int devtype, struct proc *p)
> {
[...]

Okay, I'm comparing this to what I know of how Solaris works...and the
first question I see is why struct vnode ?  I see this as being a
dangerous step as it (potentially) encourages people to do things with
the vnode that would be "bad programming" as well as putting things into
vnode which are clone-device specific.  That may well be a specious
argument in light of other purpose-specific things in vnode.

The most immeadiate difference I see is this suggests that you could
do cloning on minor-devices..which is your goal here ?

Just for comparison, a STREAMS driver which supports cloning on Solaris
works like this:

static int pfilopen(queue_t *q, dev_t *devp, int flag, int sflag, cred_t *crp)
{
        minor_t minor;

        if (sflag == CLONEOPEN) {
                pfilminor++;
                *devp = makedevice(getmajor(*devp), pfilminor);
        }

        qprocson(q);
        return 0;
}

I *really* don't think exposing "struct vnode" at this point is the
right thing to do.

Darren