this sounds like a fine thing to me.  making devices less tied to
dev_t internally in the kernel is a good thing, since dev_t is really
just a kludgy way of representing a device in a filesystem.

I wonder thought, is there any value in providing the glue to be able
to refer to the cookie as a vnode field?  v_rdev looks to be there
more for backward compatibility than anything else, but this is something
new so there is no previous name to be compatible with.  the same would
have held for the other v_ aliases defined along with v_rdev, but I guess
whoever was doing that was trying to be consistent.  my take on that
is that it's confusing the namespaces of vnodes vs. devices and it would be
better to not pretend those are vnode fields, but that's pretty subjective.

perhaps it would be useful to sketch out an example of how this scheme would
work so that the details would be clearer.  I know that matt thomas was
advocating a different scheme (and perhaps other people have other ideas),
and if we had examples of how each of them would accomplish their goals
we'd have a better notion of their benefits.

-Chuck


On Wed, Jul 05, 2000 at 05:01:11PM -0700, Jason R Thorpe 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)
> {
> 	struct foo_softc *sc;
> 	int unit = DISKUNIT(vp->v_rdev);
> 
> 	if (unit >= foo_cd.cd_ndevs ||
> 	    (sc = foo_cd.cd_devs[unit]) == NULL)
> 		return (ENXIO);
> 
> 	...
> 
> 	/* Open was successful! */
> 	vp->v_devcookie = sc;
> 	return (0);
> }
> 
> int
> fooread(struct vnode *vp, struct uio *uio, int ioflag)
> {
> 	struct foo_softc = vp->v_devcookie;
> 
> 	...
> 
> 	return (0);
> }
> 
> ...etc.
> 
> 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.
> 
> 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?
> 
> -- 
>         -- Jason R. Thorpe <thorpej@zembu.com>