tg3 ring name:

tg3 ring name: rx_std_buffers inside the structure of tg3_rx_prodring_set

what is staging tree in linux kernel?

original found at http://www.kroah.com/log/linux/linux-staging-update.html

The Linux Staging Tree, what it is and is not

It's been many months since the Linux Kernel developers conference, where the linux-staging tree was discussed and role changed. It turns out that people are still a bit confused as to what the staging tree is for, and how it works.

So here's a short summary, I'm not going into the history or background here, that's a much longer writeup that I'd be glad to do if people are interested.

The Linux Staging Tree, what it is and is not.

What the Linux Staging tree is

The Linux Staging tree (or just "staging" from now on) is used to hold stand-alone drivers and filesystems that are not ready to be merged into the main portion of the Linux kernel tree at this point in time for various technical reasons. It is contained within the main Linux kernel tree so that users can get access to the drivers much easier than before, and to provide a common place for the development to happen, resolving the "hundreds of different download sites" problem that most out-of-tree drivers have had in the past.

What the Linux Staging tree is not

The staging tree is not a place to dump code and run away, hoping that someone else will to the cleanup work for you. While there are developers available and willing to do this kind of work, you need to get them to agree to "babysit" the code in order for it to be accepted.

Location and Development

The staging tree is now contained within the main Linux kernel source tree at the location drivers/staging/. All development happens within the main kernel source tree, like any other subsystem within the kernel. This means:

The linux-next tree contains the latest version of the staging tree, with bugfixes that are about to be merged into Linus's tree, as well as the patches that are to be merged into the next major kernel release.
If you wish to do work on the staging tree, checkout the linux-next tree and send patches based on that.
Runtime

When code from the staging tree is loaded in the kernel, a warning message will be printed to the kernel log saying:

MODULE_NAME: module is from the staging directory, the quality is unknown, you have been warned.

and the kernel will be tainted with the TAINT_CRAP flag. This flag shows up in any kernel oops that might be produced after the driver has been loaded.

Note, most kernel developers have expressed the warning that they will not work on bugs for when this taint flag has happened, so if you run into a kernel problem after loading such a module, please work to reproduce the issue without a staging module loaded in order to be able to get help from the community.

If anyone has any questions that this summary doesn't answer, please let me know.

[Linux Device Driver] Good hints to analyze linux networking driver source code

There are several mandatory points that all networking drivers should implement.

Lookup hints: net_device_ops, dev_queue_xmit, netif_rx, napi_gro_receive, netif_napi_add, request_irq, open_softirq, tasklet_init, request_firmware

Those are the interfacing parts to the linux networking kernel and should be used or implemented in the drivers

for instance, net_device_ops->ndo_xmit_start is the callback function called when kernel wants to send a packet.

netif_rx or napi_gro_receive is the function that takes a skb (or skbs) that are sent to the upper layer (host).

dev_queue_xmit is for forwarding the packets at the L2 (such as L2 switching)

netif_napi_add registers napi callback for polling the device receive

request_irq takes a function pointer for interrupt handler: that is the one that called whenever a packet is delivered to the device

open_softirq and tasklet_init are starting points of bottom-half. Bottom-half is for processing heavy load part of ISR (interrupt service routine). Top-half (fast and light) and bottom-half (slow and heavy).

If driver uses request_firmware, it means that this driver loads the firmware to the micro-controller in the device.

How to write PCI driver in Linux (good start)

http://free-electrons.com/doc/pci-drivers.pdf

The packet processing function trace in ixgbe driver

How to receive packets:
Two ways:
- using napi (poll): register netpoll function to napi (ixgbe_netpoll) that performs clean the rx_ring and sends all the packet up to the upper layer
- calls ixgbe_msix_clean_rings()
- calls ixgbe_clean_tx_irq()
- calls ixgbe_receive_skb() or napi_gro_receive()

- what is the other? who writes to rx_ring???


How to send packets:
One way:
- use ixgbe_xmit_frame() function calls ixgbe_xmit_frame_ring()

What is the source code of the ethernet driver (NetXtreme BCM5761e)

it is tg3.c located at
drivers/net/tg3.c

[Linux Device Driver] intel ixgbe source code analysis (part1: where is the entry?)

ixgbe

[ixgbe_main.c] ixgbe_init_module called

[ixgbe_main.c] dca_register_notify called

[ixgbe_main.c] pci_register_driver called
-->

[ixgbe_main.c] ixgbe_probe called # here actual initialization of ethernet device is performed
/**
* ixgbe_probe - Device Initialization Routine
* @pdev: PCI device information struct
* @ent: entry in ixgbe_pci_tbl
*
* Returns 0 on success, negative on failure
*
* ixgbe_probe initializes an adapter identified by a pci_dev structure.
* The OS initialization, configuring of the adapter private structure,
* and a hardware reset occur.
**/



#endif
static struct pci_driver ixgbe_driver = {
.name = ixgbe_driver_name,
.id_table = ixgbe_pci_tbl,
.probe = ixgbe_probe,
.remove = __devexit_p(ixgbe_remove),
#ifdef CONFIG_PM
.suspend = ixgbe_suspend,
.resume = ixgbe_resume,
#endif
#ifndef USE_REBOOT_NOTIFIER
.shutdown = ixgbe_shutdown,
#endif
#ifdef HAVE_PCI_ERS
.err_handler = &ixgbe_err_handler
#endif
};