[sockbuf] Don't expose lock details when isn't needed

[davide]

I plan to commit this in two days or such, so if there are objections, please raise them.

[julian]

Is the reason here to just make the lines shorter or is there a deeper reason? (e.g. to prepare for some upcoming change)

[davide]

Mainly for consistency at this point with whatever else it's used in the stack.

[rwatson]

Seems reasonable. I'm slightly surprised that any code other than sbwait() actually implements the sleep on sb_acc, and wonder if either a use of abstraction improvement, or an actual abstraction improvement, is needed to fix t4_ddp.c.

[rwatson]

Looks like some serious transcription errors are in this patch.

sys/kern/uipc_sockbuf.c

225

Should this be so->so_rcv?

234

Should this be so->so_rcv?

[davide]

Robert,
an added (somewhat related) note.
SCTP has already its own sockbuf(s) and this makes integration very hackish in the tree. IIRC glebius experienced this himself while working on sendfile(), and I'm pretty sure rrs@ is kind of familiar with the problem. Introducing a better abstraction for sockbuf might help with this.

sys/kern/uipc_sockbuf.c

234

Thanks for spotting i'll fix up and upload a new patch.

[rrs]

The socket buffer with SCTP is just not something thats workable. There are
all sorts of pre-defined notions that closely align a socket buffer to stream-of-bytes
semantics of TCP. With UDP its never an issue, since you have all un-ordered who
cares up come the messages.

With SCTP there are all sorts of interesting ordering constraints and settings that
make it so that you can't just read from a linear socket buffer.

We definitely would need a completely different abstraction!