be inserted into ktrace records. The general change has been to replace
"struct proc *" with "struct lwp *" in various function prototypes, pass
the lwp through and use l_proc to get the process pointer when needed.
Bump the kernel rev up to 1.6V
before the reader woke up - this made the reader loop again, waiting
for another writer, even though there was input available.
Thanks to Jaromir for spotting the real cause and sugesting a solution.
This should fix PR port-sparc64/20283.
kqueue provides a stateful and efficient event notification framework
currently supported events include socket, file, directory, fifo,
pipe, tty and device changes, and monitoring of processes and signals
kqueue is supported by all writable filesystems in NetBSD tree
(with exception of Coda) and all device drivers supporting poll(2)
based on work done by Jonathan Lemon for FreeBSD
initial NetBSD port done by Luke Mewburn and Jason Thorpe
has been VOP_OPEN()'d. if the fifo is being accessed via a layered fs,
v_usecount is always one (representing the hold by the layered vnode)
regardless of how many times the vnode has been opened. instead, keep a
separate counter for opens. fixes PR 17195 and probably 17724.
as with user-land programs, include files are installed by each directory
in the tree that has includes to install. (This allows more flexibility
as to what gets installed, makes 'partial installs' easier, and gives us
more options as to which machines' includes get installed at any given
time.) The old SYS_INCLUDES={symlinks,copies} behaviours are _both_
still supported, though at least one bug in the 'symlinks' case is
fixed by this change. Include files can't be build before installation,
so directories that have includes as targets (e.g. dev/pci) have to move
those targets into a different Makefile.
1: the fi_readers and fi_writers fields of the fifoinfo structure were not
being initialized to 0. This caused the driver to not sleep the first
process to open the fifo--it thought there was already another process to
talk to (most of the time.)
2: fifo_open() was calling tsleep() without unlocking the inode of the fifo
file. This caused *any* subsequent access to the file (even an ls (!)) to
hang forever. Note that this bug was usually masked by bug #1 above.
matt