Skip navigation

Tag Archives: kernel

I am a most impressed Arch Linux user. It is best suited for my low end system. My system is PIII-800MHz/192MB/Intel-82815. After recovery of /home files from lost partition, I cleaned up all my system partitions for fresh and compact installation of Arch Linux. In last 5 months experience in Arch Linux, I tested with a lot of applications installed. Now I know what I need. So I went for fresh Arch installation, otherwise you need not to install Arch to become current version. pacman -Syu will do, to make your system current. OK, let me come to the point.

I installed base Arch installation with 0.7.2 CD in a matter of a few minutes. After reboot, configured pppoe-setup so that I could run pacman -Syu to become updated system. After update, edited /boot/grub/menu.lst and changed initrd value as kernel26.img (based on previous experience, to avoid kernel panic after reboot). This is most important step people have to remember when updating latest 2.6 kernel. So I was cool expecting clean boot, but…. resulted in kernel panic. What to do? No, problem; I have Arch base CD 0.7.2, which is also a good recovery CD.

Booted with Arch CD and entered arch root=/dev/hdX noinitrd ro at boot prompt. My Arch root partition became live. I checked /var/log/ directory for pacman log, which did not give any hint. I was not able to start my broadband cable daemon also due to some module error, as it pointed out. So I was not able to get information through internet. Then I uninstalled and re-installed both mkinitcpio and kernel26. While re-installing it showed some tips about earlymodules=piix to be appended in kernel command line for some Intel chip set based board. I did the same by editing /boot/grub/menu.lst. Now rebooted and found clean Arch Linux command prompt. That’s good. This is also one important step people have to remember when updating latest 2.6 kernel. For other chip set boards, different earlymodules= values are also available. Please search Arch forum for more info on that.

I request Arch developers to take care of this issue which often raises. It is mostly related to update of kernel command line in grub/lilo.

Additional Notes:

After base installation, how to bring GNOME desktop setup? Here is a quick go:

1. To install X windows system: pacman -S xorg

2. To install i810 video driver (for my PC): pacman -S xf86-video-i810

3. To install GNOME: pacman -S gnome-desktop gnome-extra

4. To install GNOME Display Manager (GDM): pacman -S gdm

5. Add fam, hal, portmap & dbus gdm in DAEMONS line of /etc/rc.conf file.

6. To configure the X-Windows if you don’t have high end video cards:
# hwd -u
# hwd -x
# cp /etc/X11/xorg.conf.hwd /etc/X11/xorg.conf

7. Reboot and enjoy the GDM welcome screen.


The Microsoft has released Windows CE 6.0 version yesterday. The most exciting feature for me is the share kernel source (Since I don’t do any active platform building nowadays, I don’t bother much about other features in this shiny new version. You may refer this link for more info on that.

Why I consider open kernel source as important feature in Windows CE? Reason is obvious. Windows CE is not a Server or Desktop oriented OS, but it is closely bound with hardware of the system. In my ex-profession, our team had to live with Windows CE. We intended to tune the OS to our ever changing requirements, the effort continues still. Since we have struggled a lot with debugging device driver code and not knowing the limitation of Windows CE API (which is a small sub set of Win32 API), this is definitely a big boost to my friends who work in that project still. The following are expected impact due to shared kernel source on any Windows CE based project:

1. Hard core developer of Platform builder, who takes care of configuring the system according to the hardware configuration will get more help from the kernel source which sits very much in his own IDE. Debugging the kernel mode drivers will no more be a nightmare.

2. Windows CE kernel can be customized for smaller foot print and better performance. This is absolutely necessary in the embedded world.

3. This will pause the people who intend to move to Embedded Linux for technical compulsion, and have them to re look at Window CE. The chances for support to Windows CE from both technologist and management are very well there.

4. The Shared Source License has been simplified which may affect the production cost of the end product. Any body who knows, can post a comment on this. Here is a link on license details.

5. Getting a shared source kernel for paying big $$$$ for microsoft is reasonable now… happy to see this 🙂 🙂

Happy kernel hacking, my dear Windows CE friends!

Today I read the Cathedral and Bazaar by Eric S. Raymond. It has nice quotes especially for open source programmers but equally holds true for closed source programmers also. Here are the quotes:

1. Every good work of software starts by scratching a developer’s personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. If you have the right attitude, interesting problems will find you.
4. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
5. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
6. Release early. Release often. And listen to your customers.
7. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
8. Smart data structures and dumb code works a lot better than the other way around.
9. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
10. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
11. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
12. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
13. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
14. To solve an interesting problem, start by finding a problem that is interesting to you.


This document talks about working of a ethernet card device driver in a bird’s eyeview. This is aimed at people who are interested in understanding what is happening inside the driver. If a system administrator understands this document, he/she can understand the scope of command line (ifconfig) and device driver, so that he/she need not to break his/her head with command line for something which can only be done with kernel device driver. This document can make an developer to understand the existing network device driver to some extent. This document may motivate others to start learning kernel stuff.


(a) You know that we talk here about kernel 2.4.X (not latest 2.6.X series kernel)

(b) You know that this network device driver is a a modularized kernel module. It is assumed that it is not linked into the kernel.

(c) The audience should have some basic “C” language and linux system administration skills.


I have learned about network device driver from the famous book (my favourite too!) Linux Device Drivers – 2nd Edition by Alessandro Rubini & Jonathan Corbet from O’reilly publication. This book has helped me in preparing this document. Thanks to Authors! This book is available under GPL license for download and hard copy of book is available in all leading book stores at reasonable cost.


Your feedback is valuable since I too a newbie to kernel level stuff. This is my attempt to share my understanding with others, so that jointly we can fine tune this document, which can become a starting point for any network device driver programmer. You are welcome to mail me your suggestion to my mail id of “karuppuswamy” which is hosted in gmail dot com.

Enough with header….! Now let us kick start the exciting world of linux system internal of network device drivers. The following is the basic sequence and flow of code in a network driver. It does not talk in depth specific to hardware, but what ever explained here is common to all network device drivers.

1. Detecting Hardware Device:

Once a network driver is loaded into the kernel, the driver probes for the hardware device it supports (I/O ports and IRQ line). The device found are to be registered with kernel.

2. Registration with kernel:

Usually linux drivers register itself with kernel, once it is loaded. During the registration process it asks for its unique major/minor number. There will be a corresponding file in /dev directory with major/minor number allocated for that device (e.g.: /dev/hda – hard disk partition). But when a network driver is loaded into kernel, it does not ask for major/minor number as other drivers do. There is no “everything is a file” concept for network device (it means there is NO /dev/eth0 like file, similar to /dev/hda hard disk partition). Instead, the network driver inserts a data structure (struct net_device) for each newly detected interface into a global list of network devices. This structure describes the characteristics of the found device.

3. Filling up of net_device structure:

Kernel takes care of some ethernet defaults through a function (ether_setup()), which fills several fields in the net_devie structure. Device specific fields are filled by this device driver.

4. Opening (“open” method) the device:

(a) It requests and gets allocated its memory region and IRQs.

(b) The hardware address (“MAC address” popularly known as) is copied from real hardware to net_device structure.

(c) Transmit Queue of this device is started (“netif_start_queue”) to accept packets for transmission.

Note: Before the network device is used, it must be opened by the kernel in response to “ifconfig / ifup” command. With this command an IP address is assigned to the device and device is made up (ON). Assigning IP address is happening at OSI layer 3 (Network layer – IP), so this device driver (OSI layer 2 – MAC) has nothing to do with that. But to make this device up, IFF_UP flag of net_device structure is set. Kernel calls open method of this device to do the same.

5. Transmission of Packet (“hard_start_xmit” method):

(a) Whenever the kernel needs to transmit a data packet, it calls the “hard_start_xmit” method to put the data on an outgoing queue.

(b) Kernel put the data (packet) in the form of a structure called “socket buffer structure” (struct sk_buff).

(c) Device driver does not modify this data and it does some sanity checks only. Then it transmits the data by calling highly hardware dependent routines of the device.

Note1: The “hard_start_xmit” function is protected from concurrent calls by a spinlock (xmit_lock).

Note2: The hardware interface (ethernet card) has limited memory for outgoing packets. When this memory is exhausted, the driver will tell the kernel (“netif_stop_queue”) not to start any more transmissions until the hardware is ready to accept new data. Once the driver has stopped its queue, it must arrange to restart the queue at some point in the future, when it is again able to accept packets for transmission. To do so, it should call “netif_wake_queue” method.

Note3: If the current system time exceeds the device’s “trans_start” time (which is set while a packet is transmitted) by atleast the timeout period, the networking layer will eventually call the driver’s “tx_timeout” method. That method’s job is to clear up the problem and to ensure the proper completion of any transmissions that were already in progress.

6. Receiption of Packet:

(a) When a packet is arrived at hardware, it trigges the corresponding interrupt. The interrupt handling routine of driver is called.

(b) This routine receives a pointer to the data and its length (packet), which are already available in memory. Its responsibility is to send the packet to the upper layers of networking code.

7. Closing/Releasing/Stopping (“stop” method) the device:

(a) It releases allocated memory and IRQs.

(b) Trasmit Queue of this device is stopped (“netif_stop_queue”) from accepting packets for transmission.

Note: This method is called when we issue “ifdown <dev>” command.

8. Changes in Link state:

The networking subsystem needs to know when network links go up or down, and it provides a few functions that the driver may use to convey that information. “netif_carrier_off”, “netif_carrier_on” and “netif_carrier_ok” are such functions.


I had a nice experience of going through “snull” network interface explained in the LDD3 book. Wish you all the best kernel hack hours!