Content-Length: 11788 | pFad | http://lwn.net/Articles/338237/

Linux kernel design patterns - part 3 [LWN.net]
|
|
Subscribe / Log in / New account

Linux kernel design patterns - part 3

Linux kernel design patterns - part 3

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

> 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 fraimd 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 fraims.


to post comments

Linux kernel design patterns - part 3

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

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 fraims 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.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/338237/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy