OSDev.org

Hi,

I was wondering about how networking is implemented in an operating system, up to the point we have sockets available to the user. What does the driver implement? Just the physical layer? Or does it implement full Ethernet and Internet Protocol? What layers are there between system sockets and the final data? Thanks,

JVFF

Hey jvff..

Spix on this forum recently started doing network related work on his operating system mort, He from what I can tell started out by writing basic drivers for cards, NE2000 and Realtek 8139.. Receiving broadcast packets etc..

He later started working on IP and ARP support, His next step is likely to work on ICMP/TCP/UDP and then a user interface like BSD sockets.

http://www.mort-os.com/

I'd say this would be roughly how you could start out.. Look forward to reading lot's of documentation and/or example drivers.

I am confused about what should be implemented in modules, and what should be exposed to the user. For example, is a driver just handling the physical layer? Or does it incorporate some higher layers? I think a network chip could implement the internet protocol on hardware. In that case, how can I make that available to the user, and at the same time allow flexibility with multiple modules.

For example: I have an software IP module, a software Ethernet module and some driver modules. When I want to send something, I would send data to any one of the modules (having that the IP module would send data to the Ethernet module, which would send data to the drivers). This allows me to send in IP, in pure Ethernet, or just pure data. However, if I have an IP on hardware, and I want to send data through IP, the IP module should redirect data to the hardware and format the data to send to Ethernet module to then send through the hardware without IP. Ideally the IP module shouldn't be required to know about it's lower layers. So this leads me to: how to implement it so I can allow flexibility and optimally use the hardware.

Also, if I want to send something and I have more than one NIC, should I send the data through all NICs? Thanks for your reply,

JVFF

jvff wrote:I am confused about what should be implemented in modules, and what should be exposed to the user. For example, is a driver just handling the physical layer? Or does it incorporate some higher layers? I think a network chip could implement the internet protocol on hardware. In that case, how can I make that available to the user, and at the same time allow flexibility with multiple modules.

It's pretty rare, but possible that the network chip implements higher level protocols. I've also seen chips that implement protocols up to iSCSI and even NFS. In that case however, a driver would almost replace the whole network stack to take advantage of full hardware acceleration, AFAIK that's how it's done on linux, for example.

For typical NICs (those that just implement some ethernet specific things), a driver just knows how to send and receive ethernet packets over an ethernet link. Everything above that (ip routing and stuff) should be implemented by the OS's network stack.

jvff wrote:Ideally the IP module shouldn't be required to know about it's lower layers. So this leads me to: how to implement it so I can allow flexibility and optimally use the hardware.

As far as it's possible, this seems to be the right way. AFAIK there must be at least some glue between the layers - maybe you could seperate the generic and transport specific parts into a generic ip and an ip-over-ethernet module...

jvff wrote:Also, if I want to send something and I have more than one NIC, should I send the data through all NICs? Thanks for your reply,

That's all covered in the tcp/ip specs, it depends on the packet's destination.

Thanks for yoyr reply. I assume with multiple NICs some low level layer is responsible for routing through the NICs. I know have a better understanding, thank you,

JVFF

For NIC Cards in particular, I always thought of there drivers as the data link layer, then the OS can apply whatever protocols on top of that. After browseing the Uniform Driver Interface (UDI) spec they seem to suggest the same thing. Handling the network layer as a module could help free up a dependency on IP, and should result in the ability to use other low-level protocols. To be safe, you could give driver writers the ability to override your own stack, for NIC's that can do things like IP or QOS in hardware.

Ok. As I thought, to support "wierd" or "not standard" NICs I must do some "hacks" to the structure. Seems like a small penalty for the advantages. Thanks,

JVFF