User: Password:
|
|
Subscribe / Log in / New account

Linux kernel design patterns - part 3

Linux kernel design patterns - part 3

Posted Jun 23, 2009 12:33 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

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


(Log in to post comments)

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 © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds