Re: 16 year old bug
On Tue 24 Aug 2010 at 11:10:55 -0400, der Mouse wrote: I believe that non-contiguous netmasks actually are illegal nowadays. Cite? RFC 4632 (CIDR Address Strategy), section 5.1: ...which is titled Rules for Route Advertisement. (Also, 4632 is a BCP, not a standard.) An implementation following these rules should also be generalized, so that an arbitrary network number and mask are accepted for all routing destinations. The only outstanding constraint is that the mask must be left contiguous. With respect to route aggregation in advertisements (ie, exterally-visible behaviour). See the second paragraph of 5.2. Also (thinking perversely), this never says that the 1-bits in the mask must be left-justified... a mask of 0011 1100 has the whole mask contiguous... /~\ The ASCII Mouse -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
pty(4) doco fix
I'm trying to use TIOCPKT_IOCTL, which is described in pty(4). I had to use an undocumented ioctl, TIOCEXT, to get it to work, and it worked differently than the manual page said it would. I've attached a patch for the manual page, and the new manual page, for review. All uses of TIOCPKT_IOCTL in the kernel should be reviewed. ISTR that the way it's used in sysinst doesn't accord with the documentation, old or new. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933 .\ $NetBSD: pty.4,v 1.12 2006/10/13 20:30:16 wiz Exp $ .\ .\ Copyright (c) 1983, 1991, 1993 .\ The Regents of the University of California. All rights reserved. .\ .\ Redistribution and use in source and binary forms, with or without .\ modification, are permitted provided that the following conditions .\ are met: .\ 1. Redistributions of source code must retain the above copyright .\notice, this list of conditions and the following disclaimer. .\ 2. Redistributions in binary form must reproduce the above copyright .\notice, this list of conditions and the following disclaimer in the .\documentation and/or other materials provided with the distribution. .\ 3. Neither the name of the University nor the names of its contributors .\may be used to endorse or promote products derived from this software .\without specific prior written permission. .\ .\ THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND .\ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\ ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE .\ FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\ SUCH DAMAGE. .\ .\ @(#)pty.4 8.2 (Berkeley) 11/30/93 .\ .Dd October 7, 2006 .Dt PTY 4 .Os .Sh NAME .Nm pty .Nd pseudo terminal driver .Sh SYNOPSIS .Cd pseudo-device pty Op Ar count .Sh DESCRIPTION The .Nm driver provides support for a device-pair termed a .Em pseudo terminal . A pseudo terminal is a pair of character devices, a .Em master device and a .Em slave device. The slave device provides to a process an interface identical to that described in .Xr tty 4 . However, whereas all other devices which provide the interface described in .Xr tty 4 have a hardware device of some sort behind them, the slave device has, instead, another process manipulating it through the master half of the pseudo terminal. That is, anything written on the master device is given to the slave device as input and anything written on the slave device is presented as input on the master device. .Pp In configuring, if an optional .Ar count is given in the specification, that number of pseudo terminal pairs is initially configured; the default count is 16. Additional pseudo terminal pairs are allocated on as-needed basis, maximum number of them is controlled via .Em kern.maxptys sysctl (defaults to 992). .Pp The following .Xr ioctl 2 calls apply only to pseudo terminals: .Bl -tag -width TIOCREMOTE .It Dv TIOCEXT Enable/disable .Dq external processing . This affects delivery of .Dv TIOCPKT_IOCTL packets. External processing is enabled by specifying (by reference) a nonzero .Vt int parameter and disabled by specifying (by reference) a zero .Vt int parameter. .Pp .Dv TIOCEXT is reset to its default (disabled) when the slave closes the .Nm . .It Dv TIOCSTOP Stops output to a terminal (e.g. like typing .Ql ^S ) . Takes no parameter. .It Dv TIOCSTART Restarts output (stopped by .Dv TIOCSTOP or by typing .Ql ^S ) . Takes no parameter. .It Dv TIOCPKT Enable/disable .Em packet mode. Packet mode is enabled by specifying (by reference) a nonzero .Vt int parameter and disabled by specifying (by reference) a zero .Vt int parameter. When applied to the master side of a pseudo terminal, each subsequent .Xr read 2 from the terminal will return data written on the slave part of the pseudo terminal preceded by a zero byte (symbolically defined as .Dv TIOCPKT_DATA ) , or a single byte reflecting control status information. In the latter case, the byte is an inclusive-or of zero or more of the bits: .Bl -tag -width TIOCPKT_FLUSHWRITE .It Dv TIOCPKT_FLUSHREAD whenever the read queue for the terminal is flushed. .It Dv TIOCPKT_FLUSHWRITE whenever the write queue for the terminal is flushed. .It Dv TIOCPKT_STOP whenever output to the terminal is stopped a la .Ql ^S . .It Dv TIOCPKT_START whenever output to the terminal is restarted. .It Dv TIOCPKT_DOSTOP whenever .Em t_stopc is .Ql ^S and .Em t_startc is .Ql ^Q .
Re: pty(4) doco fix
On Thu, Sep 02, 2010 at 11:40:18AM -0500, David Young wrote:
I'm trying to use TIOCPKT_IOCTL, which is described in pty(4). I had
to use an undocumented ioctl, TIOCEXT, to get it to work, and it worked
differently than the manual page said it would. I've attached a patch
for the manual page, and the new manual page, for review.
All uses of TIOCPKT_IOCTL in the kernel should be reviewed. ISTR that
the way it's used in sysinst doesn't accord with the documentation, old
or new.
I still think that the TIOCEXT doco fix is correct, but the reason
that TIOCPKT_IOCTL works differently than I expected *seems* to be a
regression in ptcread(). In NetBSD, we have this:
if (ISSET(tp-t_state, TS_ISOPEN)) {
if (pti-pt_flags PF_PKT (c = pti-pt_send)) {
pti-pt_send = 0;
mutex_spin_exit(tty_lock);
error = ureadc(c, uio);
if (error)
return (error);
/*
* Since we don't have the tty locked, there's
* a risk of messing up `t_termios'. This is
* relevant only if the tty got closed and then
* opened again while we were out uiomoving.
*/
if (pti-pt_send TIOCPKT_IOCTL) {
cc = min(uio-uio_resid,
sizeof(tp-t_termios));
uiomove((void *) tp-t_termios,
cc, uio);
}
return (0);
}
pti-pt_send is set to 0 before the test for TIOCPKT_IOCTL, so ptcread()
never writes a termios structure. I guess that we could test 'c' for
TIOCPKT_IOCTL, instead.
I compared with the code in FreeBSD. Their manual page doesn't describe
TIOCPKT_IOCTL, but it looks their pty(4) behaves the way our manual says
ours should:
if (tp-t_stateTS_ISOPEN) {
if (pt-pt_flagsPF_PKT pt-pt_send) {
error = ureadc((int)pt-pt_send, uio);
if (error)
return (error);
if (pt-pt_send TIOCPKT_IOCTL) {
cc = min(uio-uio_resid,
sizeof(tp-t_termios));
uiomove(tp-t_termios, cc, uio);
}
pt-pt_send = 0;
return (0);
}
Dave
--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: pty(4) doco fix
Hello David. If your supposition is correct, it looks to me like
things should behave the way you expect under NetBSD-4 and NetBSD-5. The
The line:
pti-pt_send = 0;
is not there under NetBSD-5 or NetBSD-4.
Have you tried your test there?
-Brian
On Sep 2, 12:06pm, David Young wrote:
} Subject: Re: pty(4) doco fix
} On Thu, Sep 02, 2010 at 11:40:18AM -0500, David Young wrote:
} I'm trying to use TIOCPKT_IOCTL, which is described in pty(4). I had
} to use an undocumented ioctl, TIOCEXT, to get it to work, and it worked
} differently than the manual page said it would. I've attached a patch
} for the manual page, and the new manual page, for review.
}
} All uses of TIOCPKT_IOCTL in the kernel should be reviewed. ISTR that
} the way it's used in sysinst doesn't accord with the documentation, old
} or new.
}
} I still think that the TIOCEXT doco fix is correct, but the reason
} that TIOCPKT_IOCTL works differently than I expected *seems* to be a
} regression in ptcread(). In NetBSD, we have this:
}
} if (ISSET(tp-t_state, TS_ISOPEN)) {
} if (pti-pt_flags PF_PKT (c = pti-pt_send)) {
} pti-pt_send = 0;
} mutex_spin_exit(tty_lock);
} error = ureadc(c, uio);
} if (error)
} return (error);
} /*
} * Since we don't have the tty locked, there's
} * a risk of messing up `t_termios'. This is
} * relevant only if the tty got closed and
then
} * opened again while we were out uiomoving.
} */
} if (pti-pt_send TIOCPKT_IOCTL) {
} cc = min(uio-uio_resid,
} sizeof(tp-t_termios));
} uiomove((void *) tp-t_termios,
} cc, uio);
} }
} return (0);
} }
}
} pti-pt_send is set to 0 before the test for TIOCPKT_IOCTL, so ptcread()
} never writes a termios structure. I guess that we could test 'c' for
} TIOCPKT_IOCTL, instead.
}
} I compared with the code in FreeBSD. Their manual page doesn't describe
} TIOCPKT_IOCTL, but it looks their pty(4) behaves the way our manual says
} ours should:
}
} if (tp-t_stateTS_ISOPEN) {
} if (pt-pt_flagsPF_PKT pt-pt_send) {
} error = ureadc((int)pt-pt_send, uio);
} if (error)
} return (error);
} if (pt-pt_send TIOCPKT_IOCTL) {
} cc = min(uio-uio_resid,
} sizeof(tp-t_termios));
} uiomove(tp-t_termios, cc, uio);
} }
} pt-pt_send = 0;
} return (0);
} }
}
} Dave
}
} --
} David Young OJC Technologies
} dyo...@ojctech.com Urbana, IL * (217) 278-3933
-- End of excerpt from David Young
