RTL8139 Driver

[RTL8139]

Can anybody tell me how to write a RTL8139 NIC driver? or tell me how this card works? I know all PnP and PCI stuff, just tell me how the card works. and how to write the driver for it. and I am NOT asking for any linux or etc driver for it, I'm asking for a datasheet or something like that. I'm designing a new OS and want to know how this NIC works.

Thanks a lot...

[Pype.Clicker]

too bad there's nothing like 'kazaa' for technical documents
i don't find anything more than mobius implementation here ... maybe when @home will recover ...

[drizzt]

You can download the RTL8139 chip specification from http://www.realtek.com.tw/downloads/dow ... TL8139C(L)

Unfortunately it is very difficult to write a driver from scratch only with this document. So it is inevitable to suggest to you to take a look at the linux driver... trust me... if you spent some time with this, you can understand more things than using only the rtl8139 doc...

If just you do not want to look at the linux driver, you can find a rtl8139 driver also in my os at http://sourceforge.net/projects/minirighi

[Tim]

I wouldn't recommend looking at the Linux driver (because I wouldn't recommend looking at Linux code ever). But most of the larger amateur operating systems have RTL8139 drivers. Look at Mobius, ReactOS and NewOS.

[Candy]

I wouldn't recommend looking at the Linux driver (because I wouldn't recommend looking at Linux code ever). But most of the larger amateur operating systems have RTL8139 drivers. Look at Mobius, ReactOS and NewOS.

I can say that the linux code does hold some good ideas... For instance, the top level makefile contains a nice way to do recursive directories.

Aside from that, I've also checked out the paging setup and booting code for i386, which contains a nice example of initializing APICs and booting up SMP machines which I couldn't find anywhere else, so I must say it was helpful.

[Tim]

I'm sure the Linux source code compiles and runs fine. However, for actually browsing through, I might as well be reading the Nepalese translation of the Koran.

[kaos]

I'm sure the Linux source code compiles and runs fine. However, for actually browsing through, I might as well be reading the Nepalese translation of the Koran.

http://lxr.linux.no is helpful.

[Pype.Clicker]

I'm sure the Linux source code compiles and runs fine. However, for actually browsing through, I might as well be reading the Nepalese translation of the Koran.

But the advantage of the Linux Kernel is that there are many well-written books about it. Once you ownz one of these books, it become more easy to get what's happening and why than looking at some other source code (except when you have the ability to talk with the code designer, like in the Mobius -- which remains a #1 reference for me )

The other advantage of looking at Linux is that it is a wide-spread massively-tested and cross-platform work, which may help you to identify specific things that you might not have noticed by working from scratch or that other coders that do not have access to a so-wide-testers-community may have ommitted (no offense).

[Candy]

Also, it's a whole lot larger project than most (or even all) of the other OS projects, which also requires a lot of organization in the code, so it details a lot of stumbling points that most projects will encounter when growing, and it also has a few techniques that, if applied in your own project, will make growing a lot easier (f.i. my own recent automation of makefile stuff) and therefore prevent you from ending up in situations where you have to adjust a lot of code without getting any real profit from it, a common deadpoint in my own projects. So, imo, if you look at other succesful projects to see some things they did, your own will have more chance to succeed

Not looking at the linux code would make your own development cycle longer.

[Pype.Clicker]

which also requires a lot of organization in the code

Oh, it's not pannacea, though, and Linux quickly become completely obscure when /proc and other stuff came in the line. Imho, Linux often fails to have the required organization ...

[Slasher]

Candy,I dont want to start a word war over here but, I've NOT looked at a single line of code from linux and i'm already at a stage where i can easily and properly support gui and networking layers with complete paging and all the necessary stuff (floppy,mouse,mm,keyboard,pic,rtc,timer,messaging,semaphore,etc) after 1yr of coding (alot of months in this year were spent doing nothing on the os. So it not Linux code that will speed up your development cycle but how well you can assimilate the info in datasheets and implement your code

[Pype.Clicker]

... all the necessary stuff (floppy,mouse,mm,keyboard,pic,rtc,timer,messaging,semaphore,etc)
...

True. For these kind of 'simple' devices, the datasheet (and the large amount of clear tutorial are usually enough. No need to look at the linux kernel to know how the keyboard should be programmed.

Now, for things like ATA-UltraDMA, PCI configuration etc., datasheets are often *way harder* to find, and giving a look at Linux's sourcecode may give you clues on how to use the informations you found. Just the fact that "woo. There's a black list of Disk manufacturers in the Ultra-dma module, which means i shouldn't rely on disk XYZ to work properly with ultra-dma because that disk has a flaw" is an interresting thing to see ...

[Tim]

Not looking at the linux code would make your own development cycle longer.

I've looked at Linux code long enough to confirm that most GNU code is unreadable. (The same applies for gcc/binutils too, except that I've actually had to fix part of binutils. That was not fun.)

IMHO the BSD code is much nicer. The BeOS sample code is superb.

[df]

i tried hacking on binutils, its a KnightMare(tm). its bloody awefull. binutils is REALLY REALLY bad. ::)

[Schol-R-LEA]

I've got a copy both Lions' Commentary on the Unix 6th Edition with Source Code of Linux Core Kernel Commentary, and I have to say, even with the excellent explanations in both, I've never been able to penetrate far into either book. In both cases, the code is hard to read and understand, with few comments and a lot of unstated assumptions. While the Linux code is, I think, better laid out for reading than the old AT&T code (heresy, I know, but then Dennis and Ken never imagined that hundreds of wannbee kernel hackers would be poring over their code for the next twenty-five years), it so much more complex that it is harder to follow than the AT&T code. Take a look at the example Maxwell starts off with, the [tt]printk()[/tt] function. The function, in a quick overview, does the following (excuse the pseudocode):

Code: Select all

get the list of consoles
put a spinlock on the consoles
read and process the varargs to get the string to print
for each line of the string
      if there is no priority setting at the start of the substring,
      add it
      for each character in the substring
           add the character to the log ring buffer, wrapping around as necessary
           increment the log character count
           if the character is a newline, end the line
       for each console
           if the priority level of the string is lower than that of the console, 
                  call the console driver to print the string
remove the spinlock from the console

(Note that I probably have at least some of this wrong; the code is very hard to follow. Maxwell picked this as an easy to understand example, too.)

This contrasts considerably with the [tt]printk()[/tt] or equivalent in most hobbyist kernels, most of which are occupied primarily with processing the variable argument string and writing to the console directly. It really does highlight the difference between a personal project and a production-grade system - the printk() function itself can't write to the hardware directly because it doesn't know what kind of consoles it must write to, or how many of them there will be, or if there are other processors which might be trying to write to the same ones as well.

However, the demands of production code do not justify the obscurity of the Linux code; it should be possible to write these functions in amanner that is clearer than they are now. Even adding more comments would be a tremendous improvement. While it is helpful to see the Linux code, to get a feel for how much more has to go into a finished product than just a basic running kernel, it is not a useful model for how to write an OS.