Dave,
Case 1 below is the situation that we have. We have a clone device that
will never return the same minor number on an open. You are right that it
will not work correctly on an I_PUNLINK under LiS, but it WILL work
correctly under every version of SVR4 Unix. I have tested this under
Solaris, HP, DEC, SCO, UnixWare, etc and they all work because they are SVR4
compliant. According to "Unix System V Relase 4 Programmer's Guide:
STREAMS", page 10-35 says:
"The persistent link can still exist even if the file descriptor associated
with the upper Stream to the multiplexing driver is closed."
This could be interpreted as meaning that one would never be able to
I_PUNLINK after closing the file descriptor to the mux driver. But on pg
10-38, they show an example of re-opening the mux driver and issuing an
I_PUNLINK.
Also, in the Addison-Wesley book "UNIX System V Network Programming", pg 584
has the following to say about persistent links:
"The persistent link mechanism is a variation of the multiplexor link
mechanism that does away with the need to have a process keep the
controlling stream open during the duration of the link. Originally
conceived and implemented by Guy Harris and Glenn Skinner at Sun
Microsystems, the persistent link mechanism was added to System V because
developers felt it was unnecessary to require that a process be used to keep
a link active and because they were worried that the original multiplexor
link mechanism would unduly complicate the process of building a protocol
stack to boot a diskless workstation over a network. ... With persistent
links, the controlling stream has no significance and can be closed after
the link is made."
So, SVR4 considers the controlling stream (or, looking at it another way,
the file descriptor originally opened) to be insignificant with regard to
I_PLINK and I_PUNLINK. The problem is that LiS doesn't work this way. From
a high level it seems that what should happen in LiS for persistent links to
work correctly is that there should be a linked list of muxids that hangs
off the file structure for the device that gets opened (e.g. /dev/mux) and
has something linked under it. Then it doesn't matter who the controlling
stream is or if it gets closed because any process could open the device and
issue a P_UNLINK with a given muxid or MUXID_ALL. This assumes that there
is some way to get from the file descriptor to the file structure for the
device.
Anyway, it seems to me that the implementation of I_PLINK and I_PUNLINK in
LiS is not the desired behavior from an SVR4 standpoint.
Paul
> -----Original Message-----
> From: David Grothe [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 04, 1999 9:38 AM
> To: Paul Stillwell
> Cc: lis-list; Alex Chamberlain
> Subject: Re: Possible PLINK/PUNLINK bug
>
>
> Bear in mind that we are discussing closing and then re-opening
> the control
> stream and then doing I_PUNLINKs. While looking at that code in
> LiS I noticed
> two things:
>
> 1. When you close a control stream that has had I_PLINKs done on it the
> STREAMS driver's close routine is not called. So the driver
> still thinks
> the stream is open. Chances are if you open a clone device
> to the same
> driver the driver will pick a different minor device number
> to return for
> the clone open than the one that is currently in use. This new minor
> device is _not_ the control stream for the multiplexor that
> has already
> been built. Therefore you cannot use it to I_PUNLINK the
> lowers, neither
> in Unix nor in LiS.
> 2. If, by some magic, the driver _does_ return the same minor
> device that is
> still open as the control stream, then LiS misses this fact.
> It writes a
> message complaining that the clone open picked a minor
> device that was
> already in use. I have fixed that so that you can allow a
> program to open
> the same minor multiple times via clone open (not published
> yet). This
> would then allow you to I_PUNLINK the lowers since you would
> have re-opened
> the control stream.
>
> This process is more predictable if you use a directed open to a
> specific minor,
> say minor 0, rather than a clone open, for your control stream.
> It is more
> predictable when you re-open that device later to re-attach to the control
> stream.
>
> -- Dave
>
> Paul Stillwell wrote:
>
> > Dave,
> >
> > So are you saying that you can't I_PUNLINK a clone device under
> UNIX? Or
> > are you saying that LiS can't I_PUNLINK a clone device?
> >
> > Paul
> >
> > -----Original Message-----
> > From: David Grothe [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, November 2, 1999 1:21 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Possible PLINK/PUNLINK bug
> >
> > Alex:
> >
> > I installed a stock LiS-2.5 and augmented it with the attached
> strtst.c and
> > Config files. The strtst.c adds a test for closing and re-opening the
> > control
> > stream of a mux after an I_PLINK was done. It demonstrates the
> ability to
> > send
> > data and to perform I_PUNLINK. An excerpt of the log file is
> also attached.
> >
> > You cannot make your suggested modification to strtst.c and expect it to
> > work.
> > That test opens a clone for the control stream. When it closes the ctl
> > streams
> > and then re-opens the minimux it will get different stdata
> structures, that
> > is,
> > different minor device numbers due to the clone open. It will
> not re-attach
> > to
> > the old stream.
> >
> > If you use a directed open, say to minor devices 1 and 2, you
> can close them
> > and
> > re-open them. When you re-open them you find that you are now
> in possession
> > of
> > the control streams of the multiplexor once again.
> >
> > -- Dave
> >
> > Alex Chamberlain wrote:
> >
> > > Hello all,
> > >
> > > I'm following up on my earlier message where I believed that
> I_PUNLINK did
> > > not work with MUXID_ALL. That turned out not to be the case (thanks,
> > Dave,
> > > I was misreading the code) but now I seem to have found a bug
> for real.
> > >
> > > The following test case will show the bug: In util/strtst.c,
> just change
> > > the PLINK/PUNLINK test code in mux_test() so that the file
> descriptors to
> > > the "upper" driver (the mini-mux driver) are closed and
> reopened after the
> > > I_PLINK calls are made and before the I_PUNLINK calls. Then
> the I_PUNLINK
> > > will fail to unlink although the ioctl() call returns 0.
> > >
> > > I added some printk's to the LiS link/unlink code in head.c
> to print some
> > > values of the "hd" pointer used to store data about the active stream
> > heads.
> > > I notice that when the link is done, in str_link_mux(), hd is
> non-null and
> > > hd->sd_mux.mx_hd is also non-null. However, in lis_i_unlink(), hd is
> > > non-null and hd->sd_mux.mx_hd is also non-null for a stream
> head that has
> > > not been closed and reopened; but the latter pointer is null
> for a stream
> > > head that *has* been closed and reopened.
> > >
> > > Thanks for any help,
> > >
> > > ---
> > > Alex Chamberlain
> > > [EMAIL PROTECTED]
> > > Polaris Communications Inc.
> > > "Products that unite the data center"
> > >
> > > -----------------------
> > *THE_LIST_HAS_MOVED* -------------------------------
> > > It is now hosted at gsyc.escet.urjc.es.
> > > To (un)subscribe send a mail to <[EMAIL PROTECTED]>
> > > To send a contribution send a mail to
> <[EMAIL PROTECTED]>
> > > Web archives for lists can be found at http://gsyc.escet.urjc.es/lists
> >
> > **********************************************************
> > Paul M. Stillwell Jr. Polaris Communications, Inc.
> > Software Engineer Check us out!
> > [EMAIL PROTECTED] http://www.polariscomm.com
> > Phone: (503) 643-1533
> > **********************************************************
> > Some days you're the dog.
> > Some days you're the hydrant.
> > ----------------------- *THE_LIST_HAS_MOVED*
> -------------------------------
> > It is now hosted at gsyc.escet.urjc.es.
> > To (un)subscribe send a mail to <[EMAIL PROTECTED]>
> > To send a contribution send a mail to
> <[EMAIL PROTECTED]>
> > Web archives for lists can be found at http://gsyc.escet.urjc.es/lists
>
>
----------------------- *THE_LIST_HAS_MOVED* -------------------------------
It is now hosted at gsyc.escet.urjc.es.
To (un)subscribe send a mail to <[EMAIL PROTECTED]>
To send a contribution send a mail to <[EMAIL PROTECTED]>
Web archives for lists can be found at http://gsyc.escet.urjc.es/lists
