Linux kernel design patterns - part 3 [LWN.net]

Linux kernel design patterns - part 3

Posted Jun 23, 2009 10:17 UTC (Tue) by hppnq (guest, #14462)
In reply to: Linux kernel design patterns - part 3 by johill
Parent article: Linux kernel design patterns - part 3

Also, you can ignore the fact that I mentioned TCP, and my point still stands with just plain IPv4, it's implemented as a midlayer.

It's not. There is no abstraction that typifies the layer. You are confusing the typical network protocol's layered design with an OS kernel design pattern.

In any case, it would be near impossible to implement networking as a library approach since afaict that would mean you'd have sockets tied to NICs and would have to provide migration for that, or something like that.

Sockets are of course bound to an interface, where appropriate. "Sockets" are a library. I must admit I am not sure what you are trying to to say here.

What could be considered a networking midlayer is the integration of network and Unix domain sockets. And that, indeed, is perhaps not such a great idea (see X11), but YMMV (see X11).

(Log in to post comments)

Linux kernel design patterns - part 3

Posted Jun 23, 2009 10:26 UTC (Tue) by johill (subscriber, #25196) [Link]

> It's not. There is no abstraction that typifies the layer. You are confusing the typical network protocol's layered design with an OS kernel design pattern.

?
No, the design is layered, but the implementation is layered as well, in Linux. It may not be layered as much, though.

> Sockets are of course bound to an interface, where appropriate. "Sockets" are a library. I must admit I am not sure what you are trying to to say here.

Well, taking a page out of the "library approach" book, you'd have to implement IP sockets in the NIC driver, by calling some functions out of the "socket" library. The NIC driver would get a socket, and then whenever something happens to the socket, call library functions to get 802.3 framed packets. Instead, however, all socket ioctls are handled directly in a layer above the NIC driver, and the NIC driver never sees the socket, but only the 802.3 frames.

Linux kernel design patterns - part 3

Posted Jun 23, 2009 12:33 UTC (Tue) by hppnq (guest, #14462) [Link]

No, the design is layered, but the implementation is layered as well, in Linux. It may not be layered as much, though.

Sorry, I missed you were mentioning the implementation specifically. The confusion was mine. ;-)

I mentioned "sockets" are actually a library, because well, they actually were, and were perceived as such especially before they became the industry standard for inter-NIC communication. In the library book, you would have to find a way to communicate through your NIC to another NIC, and sockets provide just one way to do that.

Correct me if I'm wrong: the Linux network drivers deal with socket buffers (and frames on the wire of course, in the case of ethernet), and the buffers are associated with sockets. One obvious reason for this particular aspect of the implementation is the asynchronous nature of network IO; the driver implementation cannot really in general afford to call library functions whenever "something happens to the socket".

Linux kernel design patterns - part 3

Posted Jun 23, 2009 20:29 UTC (Tue) by johill (subscriber, #25196) [Link]

Yes, data packets are called socket buffers (sk_buff) but the fact that there may or may not be a socket attached to them (sk_buff->sk) is mostly irrelevant to NIC drivers.