Re: sosend/soreceive consistency improvements



At Sun, 23 Jul 2006 19:57:56 +0100 (BST),
rwatson wrote:

Rather than continue in this "in between state", in which the
uio/mbuf chain sosend and soreceive are reached via the protocol
switch in each occurrence, I propose a change: sosend() and
soreceive() will now be the formal APIs for sending and receiveing
on sockets within the kernel, as is the case with many other so*()
functions, and they will perform the protocol switch dereference.
The existing functions are renamed to sosend_generic() and
soreceive_generic(), and in most cases are never referenced by
protocols since our protocol domain registration already uses
sosend() and soreceive() as the defaults today. The new code
strikes me as quite a bit more readable, and likely easier for
socket consumers to use.

Any thoughts and/or objections?


Makes sense to me. Can we document these? That is, is there a man
page in section 9 we could add these to?

Later,
George
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: sosend/soreceive consistency improvements
    ... As part of cleanups, locking, and optimization work, I've been looking at ... protocol could provide substitute implementations. ... There's another side to the pluggability, however -- the socket consumers ... New references to sosend() and soreceiveperiodically ...
    (freebsd-arch)
  • Re: Max Ethernet ports
    ... The protocol layer I'm converting runs on top of Ethernet & ... Does anyone make a switch where an OEM or developer can embed an application ... rides in between the uplink ports and the downstream switch ports ...
    (comp.os.linux.networking)
  • Re: weird Config... How long will this work?
    ... every switch to switch connection is done by a microwave-p2p-link ... protocol would be of benefit only to the extent that the routing ...
    (comp.dcom.sys.cisco)
  • Re: Strange switch behaviour in VLAN network
    ... I do not understand why you Disable STP states of SWITCH. ... > We have configured VLANs on all the 3Com switches and the Summits ... > EDP (extreme discovery protocol) and their VLAN tables look correct. ...
    (comp.dcom.lans.ethernet)
  • Re: Max Ethernet ports
    ... of the number - four port Ethernet cards - PCI. ... protocol numbers currently assigned. ... switch is heading in a completely different direction. ... likely cascade 8-10 port SOHO grade switches for even less. ...
    (comp.os.linux.networking)