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

> This is certainly another possible approach (although, I don't
> particularly like explcitly saying "pseudobus" ... it could all
> be done with pseudo-device and hidden inside the guts of the
> autoconfiguration code).

That'd be fine.

> It would, however, require Something Else to work .. like a system call
> which took a device name, or something.
> 
> ...otherwise, what do you do the ioctl on?

You do the ioctl on the device. Just like what you proposed in the
previous EMail. You've fixed the problem of opening an unconfigured
device. :-)

The difference all happens where you had the malloc of the softc. In the
last EMail, you just malloc'd it. Instead, we could trigger an attachment
of a new device (ccd in this example). As part of that, the config system
will malloc the softc, and call a ccdattach routine which could either do
nothing, or fill in the softc.

> The other part you didn't get the first time (because that's "step two",
> and I was trying to focus on "step one")... true cloning devices (like
> what bpf and ptys will become) will have a mechanism by which the
> upper layer devices will know that they must allocate a new vnode for
> each open and not do alias checking ... in those cases, you MUST keep
> a pointer to the softc in the vnode, because there is a *separate*
> device instance for each open, even though *the dev_t is the same*.

But vnodes don't get allocated in "open". They get allocated by the file
system in response to VOP_LOOKUP(). How will you keep the different file
systems happy with multiple vnodes each with the same inode number? When
you do a directoy lookup, the first thing the file system finds is the
inode number (or fs-specific equivalent), then it gets the vnode. ??

Take care,

Bill