Chris,
Chris Elving wrote:
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:
I agree, that part was definitely overlooked. Thanks for pointing it out.
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)
My preference here would be to add a version field, which should have a
small impact on initialization while preserving type safety.
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?
Right, ksocket is used to refer to the kernel socket, whereas ksock is
the prefix for everything else. However, I does make sense to use a
single term, so unless people have objections I will change the prefix
to ksocket.
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.
This is a shortcoming that we might be able to address through another
project.
Thanks for you comments,
Anders
_______________________________________________
networking-discuss mailing list
[email protected]
