Nick Stacky: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
(Ported OSdeving like Nick Stacky)
 
No edit summary
 
(13 intermediate revisions by 10 users not shown)
Line 1: Line 1:
His test-machine has no keyboard and no screen. No one needs that. All he needs is NICs (Network Interface Cards) ... Plenty of NICs and Ethernet cable to see if his kernel responds to pings and routes packets correctly. His kernel of course has powerful multithreading and a complete TCP/IP stack. Or maybe you want to start with [[What order should i make things in|something else]].
His test-machine has no keyboard and no screen. No one needs that. All he needs are NICs (Network Interface Cards) ... Plenty of NICs and Ethernet cable to see if his kernel responds to pings and routes packets correctly. His kernel of course has powerful multithreading and a complete TCP/IP stack. Or maybe you want to start with [[What order should I make things in|something else]].


== Nick Stacky's challenge ==
== Nick Stacky's challenge ==
=== Accessing your NIC. ===
=== Accessing your NIC. ===


# First of all, buy one. A RTL8139 preferably or a [[ne2000]], as they're well documented with well-documented [http://cvs.sourceforge.net/viewcvs.py/mobius/coreos/drivers/ hobby-drivers] available for them. The [[Bochs]] has ISA NE2K support while Qemu has it as a PCI device. Another nice card is the [[3c556]].
# First of all, buy one. A RTL8139 preferably or a [[ne2000]], as they're well documented with well-documented [http://cvs.sourceforge.net/viewcvs.py/mobius/coreos/drivers/ hobby-drivers] available for them. The [[Bochs]] has ISA NE2K support while Qemu has it as a PCI device. Another nice card is the [[3c90x]].
# Get as much documentation about those chips as you can, figure [http://profile.iiita.ac.in/aagarwal2_01/pguide.pdf how they work]
# Get as much documentation about those chips as you can, figure [http://beej.us/guide/bgnet/ how they work]
# Write/port tools that will scan the [[PCI]] bus for such device(s).
# Write/port tools that will scan the [[PCI]] bus for such device(s).


=== Sending packets ===
=== Sending packets ===


First thing, you should learn to send/receive packet on your own system. I strongly recommend the [http://www.ecst.csuchico.edu/%7Ebeej/guide/net/ Beej Programming Guide], and reading about encapsulation of protocol headers will be a must.
First thing, you should learn to send/receive packet on your own system. I strongly recommend the [http://beej.us/guide/bgnet/ Beej Programming Guide], and reading about encapsulation of protocol headers will be a must.


+--*--*--*--*--*--*--*--+--*--*--*--*--*--+--*--*--*--*--*--+--*--+----/ /--+--*--*--*--+
+--*--*--*--*--*--*--*--+--*--*--*--*--*--+--*--*--*--*--*--+--*--+----/ /--+--*--*--*--+
Line 40: Line 40:


== Nick Stacky's Bookshelf ==
== Nick Stacky's Bookshelf ==
He owns a copy of [http://www.amazon.com/Computer-Networks-Approach-Kaufmann-Networking/dp/1558605142 "Computer Networks: A Systems Approach" by Larry L. Peterson & Bruce S. Davie] that he found by chance in a local bookstore. But he hates reading much else in the print side, since reading print is too slow. He'd rather download the book from his experimental network and gaze at its virtual beauty, then go back and do it again.

He owns "Computer Networks : A Systems Approach" by Larry L. Peterson & Bruce S. Davie he founds by chance in a local bookstore. Nowadays, the book can be found [http://www.cs.arizona.edu/llp/book/book.html online]. "TCP/IP Ilustrated part I- protocols" (W Richard Stevens)- another good book.


== Nick Stacky's Opponents position ==
== Nick Stacky's Opponents position ==


A kernel should be able to do more than just answering pings. You have plenty of code following RFC, but you can't even display one on screen ... Is TCP really interresting if your kernel cannot even have programs that exchange data through those connections ? And don't talk me about your kernel-level POP/SMTP server when i talk you about programs ...
A kernel should be able to do more than just answering pings. You have plenty of code following RFC, but you can't even display a single character on screen ... Is TCP really interresting if your kernel cannot even have programs that exchange data through those connections ? And don't talk me about your kernel-level POP/SMTP server when i talk to you about user programs ...


== People and OSes related to Nick Stacky ==
== People and OSes related to Nick Stacky ==
* Pcmattman: ''Even in the first version I had a fully functional UDP/IP stack, and I always find writing the card drivers easier than other things''
{{Stub}}
* [[User:01000101|01000101]]

* '' insert your names here ''
* '' insert your names here ''


[[Category:Developer Archetype]]

Latest revision as of 17:13, 12 October 2016

His test-machine has no keyboard and no screen. No one needs that. All he needs are NICs (Network Interface Cards) ... Plenty of NICs and Ethernet cable to see if his kernel responds to pings and routes packets correctly. His kernel of course has powerful multithreading and a complete TCP/IP stack. Or maybe you want to start with something else.

Nick Stacky's challenge

Accessing your NIC.

  1. First of all, buy one. A RTL8139 preferably or a ne2000, as they're well documented with well-documented hobby-drivers available for them. The Bochs has ISA NE2K support while Qemu has it as a PCI device. Another nice card is the 3c90x.
  2. Get as much documentation about those chips as you can, figure how they work
  3. Write/port tools that will scan the PCI bus for such device(s).

Sending packets

First thing, you should learn to send/receive packet on your own system. I strongly recommend the Beej Programming Guide, and reading about encapsulation of protocol headers will be a must.

+--*--*--*--*--*--*--*--+--*--*--*--*--*--+--*--*--*--*--*--+--*--+----/ /--+--*--*--*--+
|  preamble & startbit  | destination add |   source addr   | Len | data    |    CRC    |
+-----------8-----------+--------6--------+--------6--------+--2--+----/ /--+-----4-----+

Note that for technical reasons, the "data" field must be at least of 46bytes (though "len" may be smaller) and may not be of over 1500 bytes. NIC usually doesn't check this, but failing to do so will lead to packet lost or misinterpreted by other components.

Most NIC cards use the concept of ring buffers that contain packets received (but not yet transferred to main memory) or packet to send. The NIC issues an IRQ when a packet is available in such buffer or when a packet has been successfully emitted (check out the programming guide of your card for details).

Quoting the RTL8139(a/b) pguide, you have to

  1. copy the packet to a physically continuous buffer in (main) memory
  2. write the descriptor (start address, size, and miscellaneous control values) on the card's registers

In response, the NIC will

  1. starts moving data in its xmit FIFO and will start emitting on the wire as soon as it has "enough" data (defined by the early threshold on 8139)
  2. indicates it has the whole packet in FIFO by modifying the descriptor (setting a status bit somewhere)
  3. indicates it has emitted the packet by setting another status bit
  4. trigger an interrupt if interrupts have been enabled for this operation.

Supporting IP, TCP, UDP

This page is a stub.
You can help the wiki by accurately adding more contents to it.

Going further than Nick Stacky

One difficulty for Nick is that with his all-wired OS, it can be quite difficult to change the machine setup. Here again, using one GRUB module that will contain the network configuration (IP address to use, address of the default gateway, routing table, etc.) may greatly help.

Nick Stacky's Bookshelf

He owns a copy of "Computer Networks: A Systems Approach" by Larry L. Peterson & Bruce S. Davie that he found by chance in a local bookstore. But he hates reading much else in the print side, since reading print is too slow. He'd rather download the book from his experimental network and gaze at its virtual beauty, then go back and do it again.

Nick Stacky's Opponents position

A kernel should be able to do more than just answering pings. You have plenty of code following RFC, but you can't even display a single character on screen ... Is TCP really interresting if your kernel cannot even have programs that exchange data through those connections ? And don't talk me about your kernel-level POP/SMTP server when i talk to you about user programs ...

People and OSes related to Nick Stacky

  • Pcmattman: Even in the first version I had a fully functional UDP/IP stack, and I always find writing the card drivers easier than other things
  • 01000101
  • insert your names here