Anders Persson wrote:
A kernel sockets prototype has just been pushed to the project's mercurial gate. The prototype handles TCP and UDP sockets, but SCTP and SDP sockets are not yet supported. Please check out the project page [1] on how to obtain and use the prototype.
I won't be an immediate consumer of any kernel sockets API, but it is an area of interest. After looking at the project page and the prototype, I have two suggestions.
First, the ksock_callbacks() interface seems problematic. Adding new events to ksock_callbacks_t in the future would break binary compatibility. I see two options:
a) add a version, count, size, or supported event bitmask field to the front of ksock_callback_t (at the cost of more complex ksock_callback_t initialization)
b) replace ksock_callbacks() with a function that accepts a void * function pointer and an int that specifies the event type (at the cost of losing the type safety built into ksock_callback_t)
Second, the terms ksocket and ksock are both used. I think it would be good to standardize on a single term. If that term is ksock, shouldn't the header be ksock.h?
It's very unfortunate that we can't do non-blocking ksock_recv() and ksock_send() in the context of a ksock_recv_callback_t callback. My area of expertise is HTTP. In HTTP, one can often satisfy simple GET requests with little CPU usage and no blocking. Such requests constitute the majority of web traffic -- think of all the itty bitty images on the front page of opensolaris.org -- and it would be great to service them without the performance overhead of dispatching work to another thread.
_______________________________________________ networking-discuss mailing list [email protected]
