insufficient at this moment and we can bind(2) two sockets listen on same
port number.
for real fix, we need to check inpcb table with in6pcb. we can't
find inpcb chain from particular in6pcb chain (like finding tcbtable from tcb6)
luckily RFC2553 does not talk about bind(2) behavior for IPv4 mapped.
IPv4 mapped brings in too much complexities...
position, see if there is a failed component still hanging around that
we can use instead (but still mark it as failed). This leads to more
reasonable behaviour (and fewer surprises!) when autoconfiguring and
failed (or previously failed) components are still on the system.
- Change the transmit logic to send from a pre-allocated buffer instead
of doing DMA out of the mbufs directly. Timing shows that it takes
4 times longer to map in the mbufs via the sgmap routines instead of
just copying the data! This must be fixed sometine in the future.
- A bunch of other minor fixes.
FIOASYNC ioctrl command had been forwarded from wsmux to each mouse devices
and the devices had set their own event queue async mode. But no one had took
care of the event queue's mode of wsmux itself. Wsmux should make it's own
event queue async mode when it receive FIOASYNC command.
normally lengtens the file if it's shorter than specified length
also change wording slighly, to match wording in SUS
XXX someone should check how much of SUS truncate(2) specification is true
XXX on NetBSD and update this manpage accordingly
Now that after many years on not caring we find certain popular
ftp servers are starting to obey RFC959 to the letter of the law
and will only return a list of filenames (not directories or
other filetypes) in the output of `NLST', then `LIST' is more useful
in this case. (Note that the aforementioned pedanticness means that
filename completion isn't as useful as it could be...)
Fixes [bin/8937] by David A. Gatwood <dgatwood@deepspace.mklinux.org>
oster