DOC PREVIEW
USF CS 686 - A network driver ‘framework’

This preview shows page 1-2-14-15-29-30 out of 30 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 30 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 30 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 30 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 30 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 30 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 30 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 30 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

A network driver ‘framework’OverviewSource-code layoutmodule_init()The ‘key’ statements…module_exit()Slide 7open()Slide 9stop()Slide 11hard_start_xmit()Slide 13What about reception?Simulating an interruptAdvanced Programmable Interrupt ControllerSlide 17Slide 18Our ‘ioapic.c’ modulemy_isr()Installing and removing an ISRProcessing a received packetSlide 23Triggering the interrupt…Using the ‘asm-construct’Testing our ‘framework’In-class exercise #1In-class exercise #2In-class exercise #3In-class exercise #4A network driver ‘framework’We construct a ‘skeleton’ module showing just the essential pieces of a Linux network device driverOverviewhardwaredevice driver moduleLinux operating system Kernelnetworking subsystem application program standard runtime libraries user space kernel spaceSource-code layout#include <linux/module.h>#include <linux/etherdevice.h>…typedef struct { /* driver’s private data */ } MY_DRIVERDATA;char modname[ ] = “netframe”;struct net_device *netdev;netframe.cmy_init my_exit The mandatory module- administration functions my_open() my_stop() my_hard_start_xmit() my_isr() my_get_info()The network driver’s “payload” functionsmodule_init()•This function will execute when the driver is installed in the kernel (‘/sbin/insmod’)•Its role is to allocate and partially initialize a ‘struct net_device’ object for our network interface controller (i.e., hardware device), then “register” that object with the kernel•For ethernet NICs there exists a kernel helper-function that drivers can utilizeThe ‘key’ statements… typedef struct { /* the driver’s private data */ } MY_DRIVERDATA; struct net_device *netdev; static int __init my_init( void ) {netdev = alloc_etherdev( sizeof( MY_DRIVERDATA ) );if ( !netdev ) return –ENOMEM;netdev->open = my_open;netdev->stop = my_stop;netdev->hard_start_xmit = my_hard_start_xmit;return register_netdev( netdev );}module_exit()•This function will execute when the driver is removed from the kernel (‘/sbin/rmmod’)•Its role is to “unregister” the ‘net_device’ structure and free the memory that was allocated during the module’s initializationThe ‘key’ statements… struct net_device *netdev; static void __exit my_exit( void ) {unregister_netdev( netdev );free_netdev( netdev ); }open()•The kernel will call this function when the system administrator “configures” the NIC (e.g., with the ‘/sbin/ifconfig’ command) to assign an IP-address to the interface and and bring it UP•Thus the role of ‘open()’ would be to reset the hardware to a known working state and initiate packet-queueing by the kernelThe ‘key’ statements… int my_open( struct net_device *dev ) {/* initialize any remaining ‘private’ data *//* prepare the hardware for operation *//* install an Interrupt Service Routine *//* enable the NIC to generate interrupts */netif_start_queue( netdev );return 0; //SUCCESS }stop() •The kernel will call this function when the NIC is brought DOWN (i.e., to turn off its transmission and reception of packets)•This could occur because of a command (such as ‘/sbin/ifconfig’) executed by the System Administrator, or because a user is removing the driver-module from the kernel (with the ‘/sbin/rmmod’ command)The ‘key’ statements… int my_stop( struct net_device *dev ) {netif_stop_queue( netdev );/* kill any previously scheduled ‘tasklets’ (or other deferred work) *//* turn off the NIC’s transmit and receive engines *//* disable the NIC’s ability to generate interrupts *//* delete the NIC’s Interrupt Service Routine */return 0; //SUCCESS }hard_start_xmit()•The kernel will call this function whenever it has data that it wants the NIC to transmit•The kernel will supply the address for a socket-buffer (‘struct sk_buff’) that holds the packet-data that is to be transmitted •So this function’s duties are: to initiate transmission, update relevant statistics, and then release that ‘sk_buff’ structureThe ‘key’ statements… int my_hard_start_xmit( struct sk_buff *skb, struct net_device *dev ) {/* code goes here to initiate transmission by the hardware */dev->trans_start = jiffies;dev->stats.tx_packets += 1;dev->stats.tx_bytes += skb->len;dev_kfree_skb( skb );return 0; //SUCCESS }What about reception?•The NIC hardware receives data-packets asynchronously – not at a time of its own choosing – and we don’t want our system to be ‘stalled’ doing ‘busy-waiting’•Thus an interrupt handler is normally used to detect and arrange for received packets to be validated and dispatched to upper layers in the kernel’s network subsystemSimulating an interrupt•Our network device-driver ‘framework’ was only designed for demonstration purposes; it does not work with any actual hardware•But we can use a ‘software interrupt’ that will trigger the execution of our ISR •To implement this scheme, we’ll need to employ an otherwise unused IRQ-number, along with its associated ‘Interrupt-ID’Advanced Programmable Interrupt ControllerMulti-CORE CPUCPU0CPU1I/OAPICLOCALAPICLOCALAPIC●●●IRQ0IRQ1IRQ2IRQ3IRQ23 The I/O APIC component is programmable – its 24 inputs can be assigned to interrupt ID-numbers in the range 0x20..0xFF (lower numbers are reserved by Intel for the CPU’s exception-vectors)The I/O-APIC’s 24 Redirection Table registers determine these assignments•The I/O APIC in our classroom machines supports 24 Interrupt-Request input-lines•Its 24 programmable registers determine how interrupt-signals get routed to CPUs Two-dozen IRQsRedirection-tableRedirection Table Entryreservedreserved interrupt vectorID L/PSTATUSH/LRIRRE/LMASK extended destination 63 56 55 48 32 destination 31 16 15 14 13 12 11 10 9 8 7 0 delivery mode 000 = Fixed001 = Lowest Priority010 = SMI 011 = (reserved)100 = NMI101 = INIT110 = (reserved)111 = ExtINTTrigger-Mode (1=Edge-triggered, 0=Level-triggered)Remote IRR (for Level-Triggered only) 0 = Reset when EOI received from Local-APIC 1 = Set when Local-APICs accept Level-Interrupt sent by IO-APICInterrupt Input-pin Polarity (1=Active-High, 0=Active-Low)Destination-Mode (1=Logical, 0=Physical)Delivery-Status (1=Pending, 0=Idle)Our ‘ioapic.c’ module•Last semester we


View Full Document

USF CS 686 - A network driver ‘framework’

Documents in this Course
Load more
Download A network driver ‘framework’
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view A network driver ‘framework’ and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view A network driver ‘framework’ 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?