>
> When a clone open occurs the initial open is to {clone,maj} with the
> driver's open routine being called with {maj,0} and the clone flag
> set. The driver returns an updated {maj,min} to use. If this {maj,min} is
> currently not open then STREAMS simply uses the stream head structure that
> was originally for {clone,maj} to operate {maj,min}.
>
> So far, so good.
>
> But what happens if a clone open returns a {maj,min} that is already
> open? At the moment, LiS does NOT call the open routine of the driver that
> owns {maj,min}, on the theory that the driver open routine was already
> called via the clone driver.
You've lost me here. How could a clone open return a (maj,min) that is already open
WITHOUT calling the open routine
of the driver that owns {maj} (never mind minor). I'm under the impression that
selection of minor in a cloneopen is entirely
up to the specific driver.
However, in the case of a non-cloneopen of the same minor device (i believe a lot of
pseudo-ttys are implemented this way, the incoming daemon such as telnetd does a clone
open, then somehow determines the minor number to do a non-clone open for login on an
existing device) ... then the drivers open routine should be called just as it would
always be, but close only called once.
Now if the drivers CLONEOPEN return's an already opened minor device (when by
definition it should always return a new unused
minor number) then in my experience all hell breaks loose :-) ... The OS has already
allocated a STREAM, stream head, queues that it expects to be unique and it's not. At
some later point you get a panic that takes an incredibly painful process to debug ...
not that I've ever written such a buggy driver. <grin>
Ragnar
>
> But is that correct? An alternate theory is that a clone open to an
> already-open {maj,min} could be seen as a indirect open to that stream and
> that normal re-open semantics would be to call the open routines.
>
> Does anyone have any direct evidence of what other STREAMS implementations
> do in this case? I don't have a Solaris test case for this.
>
> Thanks,
> Dave
>
>
> _______________________________________________
> Linux-streams mailing list
> [EMAIL PROTECTED]
> http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
>
_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
