clean up ordering; don't lose stuff that arrives during uiomove

lint

remove unused (and sometimes missing) second arg to sodisconnect

clean up cluster allocation

oops, don't want to remove mbufs while peeking!

change datagram queuing, full packet on one chain; allow rights
in streams

add SO_TYPE option (get only!), correct mbuf lengths

allow select on exceptional conditions to notify of urgent data pending;
connect on connected datagram socket does disconnect first; error status
socket option

use the macro

Add copyright

reverse sense of pid/pgrp for fcntl, SIOCSPGRP (pgrp is negative)

oops, forgot one

allow raw sockets of any protocol if a wildcard raw entry is found;
pass protocol number to PRU_ATTACH for above;
use mbuf clusters for sends of >= NBPG;
send access rights once only if more than 1 m

allow raw sockets of any protocol if a wildcard raw entry is found;
pass protocol number to PRU_ATTACH for above;
use mbuf clusters for sends of >= NBPG;
send access rights once only if more than 1 mbuf of ordinary data;
fix PEEK moff code in soreceive

show more ...

allow zero-length sends; fix race when blocking in uiomove
by getting EPIPE from usrreq if disconnected; M_WAIT is here

last arg of pr_ctloutput(PRCO_SETOPT... is **mbuf for consistency

ctloutput calls to protocol

revise socket option interface so options at SOL_SOCKET take value
parameter indicating if option is on/off

Change to includes. no more ../h

change datagram queuing to use m_act properly; type mbufs with rights;
change protocol family number in protosw to pointer to domain (for sam)

try to remain page-aligned in sosend, even if that means waiting

seem to need to call usrreq at splnet...

rework sosend: no EWOULDBLOCK after partial write; allow zero-length
datagrams; eliminate goto's and untwist loop; simplify space calculation
(still wrong, but won't send partial datagrams!)

prevent inner loop in sosend from queuing more than "space" bytes;
temporary fix to prevent 64K writes from crashing us.

4.2 distribution

panic too punitive? we'll see ...