Re: pending changes for TOE support

> I think we should make a best faith effort to figure out how to do the right
> thing.  Employing harsh interrogation tactics is probably not called for, but
> we have several vendors who are regularly involved in the FreeBSD community
> and may be willing to lend their insight as to their requirements, even if an
> implementation isn't immediately forthcoming.

:-) - the two vendors that I know of have not been active in the
community. Sam has initiated contact on my behalf with the one vendor
that might be willing to talk to us. The other vendor has an
established pattern of ignoring all requests.

>
> >> tcp_output() was previously an internal function of the TCP code, and now
> >> the semantics are being exposed to device drivers.  Let's not perpetuate
> >> poorly documented driver interfaces by adding another one.  I think it
> >> would be a reasonable expectation of a driver author to have consistent
> >> documentation of the life cycle of data structures and objects, locking
> >> expectations and requirements, and the semantics for error values from
> >> functions.  Certainly, they need to look at TCP a fair amount because
> >> they'll be pulling things out of inpcb, tcpcb, etc, but I'd rather we limit
> >> that requirement to simple things (addresses, socket options) that are
> >> relatively static and avoid it being for complex things (locking, error
> >> handling) that tend to be more subject to change.  Also, if you document
> >> what you think the behavior is or should be, we can then check to see if we
> >> agree.
> >
> > To the extent possible, yes. I'm not convinced that anyone person knows what
> > all the existing invariants are in the stack as it is now. Do you feel that
> > a Stevens'-esque understanding of the environment around the calls is
> > necessary? I know it sounds like "other people beat their wives so I can
> > too", but even something as well documented as ifnet gives no indication of
> > what the locking conventions - e.g. you can't sleep or acquire sx locks in
> > if_ioctl. The demands placed should be no greater than those placed on
> > existing subsystems and should take into account the hitherto somewhat black
> > box nature of TCP.
>
> Actually, what I was asking for in the omitted context above was something
> along the lines of the following, adapted for whatever the reality may be:
>
>    Returning a non-zero value will lead to the software stack beginning a
>    disconnect.
>
> Or, say,
>
>    Non-zero return values will be ignored. (*)
>
> This is not intended as a contrarian point.  I'm not looking for a complete
> exposition of the behavior of the stack -- rather, basic information that we
> should be documenting about a KPI, such as what an error being returned will
> do.

That is quite reasonable. I perceived your initial request as being
entirely too open-ended.

 -Kip