The char driver interface is relatively clean and easy to use; the block interface, unfortunately, is a little messier. Kernel developers like to complain about it. There are two reasons for this state of affairs. The first is simple history -- the block interface has been at the core of every version of Linux since the first, and it has proved hard to change. The other reason is performance. A slow char driver is an undesirable thing, but a slow block driver is a drag on the entire system. As a result, the design of the block interface has often been influenced by the need for speed.

The block driver interface has evolved significantly over time. As with the rest of the book, we cover the 2.4 interface in this chapter, with a discussion of the changes at the end. The example drivers work on all kernels between 2.0 and 2.4, however.

As always, these example drivers gloss over many of the issues found in real block drivers; their purpose is to demonstrate the interface that such drivers must work with. Real drivers will have to deal with hardware, so the material covered in Chapter 8, "Hardware Management" and Chapter 9, "Interrupt Handling" will be useful as well.

One quick note on terminology: the word block as used in this book refers to a block of data as determined by the kernel. The size of blocks can be different in different disks, though they are always a power of two. A sectoris a fixed-size unit of data as determined by the underlying hardware. Sectors are almost always 512 bytes long.

 #include <linux/fs.h> int register_blkdev(unsigned int major, const char *name,      struct block_device_operations *bdops); int unregister_blkdev(unsigned int major, const char *name); 

The arguments have the same general meaning as for char devices, and major numbers can be assigned dynamically in the same way. So the sbull device registers itself in almost exactly the same way as scull did:

  result = register_blkdev(sbull_major, "sbull", &sbull_bdops); if (result < 0) {     printk(KERN_WARNING "sbull: can't get major %d\n",sbull_major);     return result; } if (sbull_major == 0) sbull_major = result; /* dynamic */ major = sbull_major; /* Use `major' later on to save typing */ 

 struct block_device_operations {     int (*open) (struct inode *inode, struct file *filp);     int (*release) (struct inode *inode, struct file *filp);     int (*ioctl) (struct inode *inode, struct file *filp,                     unsigned command, unsigned long argument);     int (*check_media_change) (kdev_t dev);     int (*revalidate) (kdev_t dev); }; 

The bdops structure used in sbull is as follows:

  struct block_device_operations sbull_bdops = {     open:               sbull_open,     release:            sbull_release,     ioctl:              sbull_ioctl,     check_media_change: sbull_check_change,     revalidate:         sbull_revalidate, }; 

Clearly, a block driver must eventually provide some mechanism for actually doing block I/O to a device. In Linux, the method used for these I/O operations is called request; it is the equivalent of the "strategy'' function found on many Unix systems. The request method handles both read and write operations and can be somewhat complex. We will get into the details of request shortly.

 #include <linux/blkdev.h> blk_init_queue(request_queue_t *queue, request_fn_proc *request); blk_cleanup_queue(request_queue_t *queue); 

The init function sets up the queue, and associates the driver's request function (passed as the second parameter) with the queue. It is necessary to call blk_cleanup_queue at module cleanup time. The sbull driver initializes its queue with this line of code:

  blk_init_queue(BLK_DEFAULT_QUEUE(major), sbull_request); 

 struct blk_dev_struct {     request_queue_t	request_queue;     queue_proc		*queue;     void		*data; }; 

The request_queue member contains the I/O request queue that we have just initialized. We will look at the queue member shortly. The data field may be used by the driver for its own data -- but few drivers do so.

Figure 12-1 visualizes the main steps a driver module performs to register with the kernel proper and deregister. If you compare this figure with Figure 2-1, similarities and differences should be clear.

The sbull device allows you to set these values at load time, and they apply to all the minor numbers of the sample driver. The variable names and their default values in sbull are as follows:

size=2048 (kilobytes)

Each RAM disk created by sbull takes two megabytes of RAM.

blksize=1024 (bytes)

The software "block'' used by the module is one kilobyte, like the system default.

hardsect=512 (bytes)

The sbull sector size is the usual half-kilobyte value.

rahead=2 (sectors)

Because the RAM disk is a fast device, the default read-ahead value is small.

The sbull device also allows you to choose the number of devices to install. devs, the number of devices, defaults to 2, resulting in a default memory usage of four megabytes -- two disks at two megabytes each.

The initialization of these arrays in sbullis done as follows:

  read_ahead[major] = sbull_rahead; result = -ENOMEM; /* for the possible errors */  sbull_sizes = kmalloc(sbull_devs * sizeof(int), GFP_KERNEL); if (!sbull_sizes)     goto fail_malloc; for (i=0; i < sbull_devs; i++) /* all the same size */     sbull_sizes[i] = sbull_size; blk_size[major]=sbull_sizes;  sbull_blksizes = kmalloc(sbull_devs * sizeof(int), GFP_KERNEL); if (!sbull_blksizes)     goto fail_malloc; for (i=0; i < sbull_devs; i++) /* all the same blocksize */     sbull_blksizes[i] = sbull_blksize; blksize_size[major]=sbull_blksizes;  sbull_hardsects = kmalloc(sbull_devs * sizeof(int), GFP_KERNEL); if (!sbull_hardsects)     goto fail_malloc; for (i=0; i < sbull_devs; i++) /* all the same hardsect */     sbull_hardsects[i] = sbull_hardsect; hardsect_size[major]=sbull_hardsects; 

For brevity, the error handling code (the target of the fail_malloc goto) has been omitted; it simply frees anything that was successfully allocated, unregisters the device, and returns a failure status.

  for (i = 0; i < sbull_devs; i++)         register_disk(NULL, MKDEV(major, i), 1, &sbull_bdops,                         sbull_size << 1); 

In the 2.4.0 kernel, register_disk does nothing when invoked in this manner. The real purpose of register_disk is to set up the partition table, which is not supported by sbull. All block drivers, however, make this call whether or not they support partitions, indicating that it may become necessary for all block devices in the future. A block driver without partitions will work without this call in 2.4.0, but it is safer to include it. We revisit register_disk in detail later in this chapter, when we cover partitions.

The cleanup function used by sbull looks like this:

  for (i=0; i<sbull_devs; i++)     fsync_dev(MKDEV(sbull_major, i)); /* flush the devices */ unregister_blkdev(major, "sbull"); /*  * Fix up the request queue(s)  */ blk_cleanup_queue(BLK_DEFAULT_QUEUE(major));  /* Clean up the global arrays */ read_ahead[major] = 0; kfree(blk_size[major]); blk_size[major] = NULL; kfree(blksize_size[major]); blksize_size[major] = NULL; kfree(hardsect_size[major]); hardsect_size[major] = NULL; 

If you look at blk.h, you'll see that several device-dependent symbols are declared according to the value of MAJOR_NR, which is expected to be known in advance. However, if the major number is dynamically assigned, the driver has no way to know its assigned number at compile time and cannot correctly define MAJOR_NR. If MAJOR_NR is undefined, blk.hcan't set up some of the macros used with the request queue. Fortunately, MAJOR_NR can be defined as an integer variable and all will work fine for add-on block drivers.

The sbull driver declares the symbols in the following way:

  #define MAJOR_NR sbull_major /* force definitions on in blk.h */ static int sbull_major; /* must be declared before including blk.h */  #define DEVICE_NR(device) MINOR(device)  /* has no partition bits */ #define DEVICE_NAME "sbull"              /* name for messaging */ #define DEVICE_INTR sbull_intrptr        /* pointer to bottom half */ #define DEVICE_NO_RANDOM                 /* no entropy to contribute */ #define DEVICE_REQUEST sbull_request #define DEVICE_OFF(d) /* do-nothing */  #include <linux/blk.h>  #include "sbull.h"        /* local definitions */ 

The Request Queue

When the kernel schedules a data transfer, it queues the request in a list, ordered in such a way that it maximizes system performance. The queue of requests is then passed to the driver's request function, which has the following prototype:

 void request_fn(request_queue_t *queue); 

The request function should perform the following tasks for each request in the queue:

Based on the previous description, a minimal request function, which does not actually transfer any data, would look like this:

  void sbull_request(request_queue_t *q) {     while(1) {         INIT_REQUEST;         printk("<1>request %p: cmd %i sec %li (nr. %li)\n", CURRENT,                CURRENT->cmd,                CURRENT->sector,                CURRENT->current_nr_sectors);         end_request(1); /* success */     } } 

Although this code does nothing but print messages, running this function provides good insight into the basic design of data transfer. It also demonstrates a couple of features of the macros defined in <linux/blk.h>. The first is that, although the while loop looks like it will never terminate, the fact is that the INIT_REQUEST macro performs a return when the request queue is empty. The loop thus iterates over the queue of outstanding requests and then returns from the request function. Second, the CURRENT macro always describes the request to be processed. We get into the details of CURRENT in the next section.

A block driver using the request function just shown will actually work -- for a short while. It is possible to make a filesystem on the device and access it for as long as the data remains in the system's buffer cache.

This empty (but verbose) function can still be run in sbull by defining the symbol SBULL_EMPTY_REQUEST at compile time. If you want to understand how the kernel handles different block sizes, you can experiment with blksize= on the insmod command line. The empty request function shows the internal workings of the kernel by printing the details of each request.

Performing the Actual Data Transfer

There are other fields in the structure, but they are primarily meant for internal use in the kernel; the driver is not expected to use them.

The implementation for the working requestfunction in the sbull device is shown here. In the following code, the Sbull_Dev serves the same function as Scull_Dev, introduced in "Section 3.6, "scull's Memory Usage"" in Chapter 3, "Char Drivers".

  void sbull_request(request_queue_t *q) {     Sbull_Dev *device;     int status;      while(1) {         INIT_REQUEST;  /* returns when queue is empty */          /* Which "device" are we using? */         device = sbull_locate_device (CURRENT);         if (device == NULL) {             end_request(0);             continue;         }          /* Perform the transfer and clean up. */ 	spin_lock(&device->lock);         status = sbull_transfer(device, CURRENT);         spin_unlock(&device->lock);         end_request(status);      } } 

This code looks little different from the empty version shown earlier; it concerns itself with request queue management and pushes off the real work to other functions. The first, sbull_locate_device, looks at the device number in the request and finds the right Sbull_Dev structure:

  static Sbull_Dev *sbull_locate_device(const struct request *req) {     int devno;     Sbull_Dev *device;      /* Check if the minor number is in range */     devno = DEVICE_NR(req->rq_dev);     if (devno >= sbull_devs) {         static int count = 0;         if (count++ < 5) /* print the message at most five times */             printk(KERN_WARNING "sbull: request for unknown device\n");         return NULL;     }     device = sbull_devices + devno; /* Pick it out of device array */     return device; } 

The only "strange'' feature of the function is the conditional statement that limits it to reporting five errors. This is intended to avoid clobbering the system logs with too many messages, since end_request(0) already prints an "I/O error'' message when the request fails. The static counter is a standard way to limit message reporting and is used several times in the kernel.

The actual I/O of the request is handled by sbull_transfer:

  static int sbull_transfer(Sbull_Dev *device, const struct request *req) {     int size;     u8 *ptr;          ptr = device->data + req->sector * sbull_hardsect;     size = req->current_nr_sectors * sbull_hardsect;      /* Make sure that the transfer fits within the device. */     if (ptr + size > device->data + sbull_blksize*sbull_size) {         static int count = 0;         if (count++ < 5)             printk(KERN_WARNING "sbull: request past end of device\n");         return 0;     }      /* Looks good, do the transfer. */     switch(req->cmd) {         case READ:             memcpy(req->buffer, ptr, size); /* from sbull to buffer */             return 1;         case WRITE:             memcpy(ptr, req->buffer, size); /* from buffer to sbull */             return 1;         default:             /* can't happen */             return 0;     } } 

The queue is designed with physical disk drives in mind. With disks, the amount of time required to transfer a block of data is typically quite small. The amount of time required to position the head (seek) to do that transfer, however, can be very large. Thus the Linux kernel works to minimize the number and extent of the seeks performed by the device.

Two things are done to achieve those goals. One is the clustering of requests to adjacent sectors on the disk. Most modern filesystems will attempt to lay out files in consecutive sectors; as a result, requests to adjoining parts of the disk are common. The kernel also applies an "elevator'' algorithm to the requests. An elevator in a skyscraper is either going up or down; it will continue to move in those directions until all of its "requests'' (people wanting on or off) have been satisfied. In the same way, the kernel tries to keep the disk head moving in the same direction for as long as possible; this approach tends to minimize seek times while ensuring that all requests get satisfied eventually.

These requests are, of course, of type struct request; we have already looked at some of the fields in this structure. The reality of the request structure is a little more complicated, however; understanding it requires a brief digression into the structure of the Linux buffer cache.

The request structure and the buffer cache

char *b_data;

The actual data block associated with this buffer head.

unsigned long b_size;

The size of the block pointed to by b_data.

kdev_t b_rdev;

The device holding the block represented by this buffer head.

unsigned long b_rsector;

The sector number where this block lives on disk.

struct buffer_head *b_reqnext;

A pointer to a linked list of buffer head structures in the request queue.

void (*b_end_io)(struct buffer_head *bh, int uptodate);

A pointer to a function to be called when I/O on this buffer completes. bh is the buffer head itself, and uptodate is nonzero if the I/O was successful.

Requests are not made of random lists of buffers; instead, all of the buffer heads attached to a single request will belong to a series of adjacent blocks on the disk. Thus a request is, in a sense, a single operation referring to a (perhaps long) group of blocks on the disk. This grouping of blocks is called clustering, and we will look at it in detail after completing our discussion of how the request list works.

Request queue manipulation

All of these functions require that the io_request_lock be held, which we will discuss next.

The I/O request lock

In Linux 2.2 and 2.4, all request queues are protected with a single global spinlock called io_request_lock. Any code that manipulates a request queue must hold that lock and disable interrupts, with one small exception: the very first entry in the request queue is (by default) considered to be owned by the driver. Failure to acquire the io_request_lock prior to working with the request queue can cause the queue to be corrupted, with a system crash following shortly thereafter.

Note, however, that the io_request_lock is an expensive resource to hold. As long as your driver holds this lock, no other requests may be queued to any block driver in the system, and no other request functions may be called. A driver that holds this lock for a long time may well slow down the system as a whole.

A variant of this latter case can also occur if your request function returns while an I/O request is still active. Many drivers for real hardware will start an I/O operation, then return; the work is completed in the driver's interrupt handler. We will look at interrupt-driven block I/O in detail later in this chapter; for now it is worth mentioning, however, that the request function can be called while these operations are still in progress.

Some drivers handle request function reentrancy by maintaining an internal request queue. The request function simply removes any new requests from the I/O request queue and adds them to the internal queue, which is then processed through a combination of tasklets and interrupt handlers.

How the blk.h macros and functions work

Of the two, INIT_REQUEST is the simpler; all it really does is make a couple of consistency checks on the request queue and cause a return from the requestfunction if the queue is empty. It is simply making sure that there is still work to do.

The bulk of the queue management work is done by end_request. This function, remember, is called when the driver has processed a single "request'' (actually one buffer); it has several tasks to perform:

 int end_that_request_first(struct request *req, int status, char *name); 

 void end_that_request_last(struct request *req); 

In end_request this step is handled with this code:

 struct request *req = CURRENT; blkdev_dequeue_request(req); end_that_request_last(req); 

That is all there is to it.

Clustered Requests

1. Arrange to transfer the data block at address bh->b_data, of size bh->b_size bytes. The direction of the data transfer is CURRENT->cmd (i.e., either READ or WRITE).

2. Retrieve the next buffer head in the list: bh->b_reqnext. Then detach the buffer just transferred from the list, by zeroing its b_reqnext -- the pointer to the new buffer you just retrieved.

3. Update the request structure to reflect the I/O done with the buffer that has just been removed. Both CURRENT->hard_nr_sectors and CURRENT->nr_sectors should be decremented by the number of sectors (not blocks) transferred from the buffer. The sector numbers CURRENT->hard_sector and CURRENT->sector should be incremented by the same amount. Performing these operations keeps the request structure consistent.

4. Loop back to the beginning to transfer the next adjacent block.

 bh->b_end_io(bh, status); 

Your driver can still use end_request (as opposed to manipulating the queue directly) at the completion of the I/O operation, as long as it takes care to set the CURRENT->bh pointer properly. This pointer should either be NULL or it should point to the last buffer_head structure that was transferred. In the latter case, the b_end_io function should not have been called on that last buffer, since end_request will make that call.

A full-featured implementation of clustering appears in drivers/block/floppy.c, while a summary of the operations required appears in end_request, in blk.h. Neither floppy.c nor blk.h are easy to understand, but the latter is a better place to start.

The active queue head

 blk_queue_headactive(request_queue_t *queue, int active); 

If active is 0, the kernel will be able to make changes to the head of the request queue.

Multiqueue Block Drivers

Consider a driver that is handling real disk devices. Each disk is capable of operating independently; the performance of the system is sure to be better if the drives could be kept busy in parallel. A simple driver based on a single queue will not achieve that -- it will perform operations on a single device at a time.

It would not be all that hard for a driver to walk through the request queue and pick out requests for independent drives. But the 2.4 kernel makes life easier by allowing the driver to set up independent queues for each device. Most high-performance drivers take advantage of this multiqueue capability. Doing so is not difficult, but it does require moving beyond the simple <linux/blk.h> definitions.

The sbull driver, when compiled with the SBULL_MULTIQUEUE symbol defined, operates in a multiqueue mode. It works without the <linux/blk.h> macros, and demonstrates a number of the features that have been described in this section.

  request_queue_t queue; int busy; 

The busy flag is used to protect against request function reentrancy, as we will see.

  for (i = 0; i < sbull_devs; i++) {     blk_init_queue(&sbull_devices[i].queue, sbull_request);     blk_queue_headactive(&sbull_devices[i].queue, 0); } blk_dev[major].queue = sbull_find_queue; 

You might be wondering how the kernel manages to find the request queues, which are buried in a device-specific, private structure. The key is the last line just shown, which sets the queue member in the global blk_dev structure. This member points to a function that has the job of finding the proper request queue for a given device number. Devices using the default queue have no such function, but multiqueue devices must implement it. sbull's queue function looks like this:

  request_queue_t *sbull_find_queue(kdev_t device) {     int devno = DEVICE_NR(device);      if (devno >= sbull_devs) {         static int count = 0;         if (count++ < 5) /* print the message at most five times */             printk(KERN_WARNING "sbull: request for unknown device\n");         return NULL;     }     return &sbull_devices[devno].queue; } 

Like the request function, sbull_find_queue must be atomic (no sleeping allowed).

  void sbull_request(request_queue_t *q) {     Sbull_Dev *device;     struct request *req;     int status;      /* Find our device */     device = sbull_locate_device (blkdev_entry_next_request(&q->queue_head));     if (device->busy) /* no race here - io_request_lock held */         return;     device->busy = 1;      /* Process requests in the queue */     while(! list_empty(&q->queue_head)) {      /* Pull the next request off the list. */         req = blkdev_entry_next_request(&q->queue_head);         blkdev_dequeue_request(req);         spin_unlock_irq (&io_request_lock);         spin_lock(&device->lock);      /* Process all of the buffers in this (possibly clustered) request. */         do {             status = sbull_transfer(device, req);         } while (end_that_request_first(req, status, DEVICE_NAME));         spin_unlock(&device->lock);         spin_lock_irq (&io_request_lock);         end_that_request_last(req);     }     device->busy = 0; } 

Each call to sbull_transfer handles exactly one buffer_head structure attached to the request. The function then calls end_that_request_first to dispose of that buffer, and, if the request is complete, goes on to end_that_request_last to clean up the request as a whole.

end_that_request_first is called without the io_request_lock held. Since this function operates only on the given request structure, calling it this way is safe -- as long as the request is not on the queue. The call to end_that_request_last, however, requires that the lock be held, since it returns the request to the request queue's free list. The function also always exits from the outer loop (and the function as a whole) with the io_request_lock held and the device lock released.

Multiqueue drivers must, of course, clean up all of their queues at module removal time:

  for (i = 0; i < sbull_devs; i++)         blk_cleanup_queue(&sbull_devices[i].queue); blk_dev[major].queue = NULL; 

It is worth noting, briefly, that this code could be made more efficient. It allocates a whole set of request queues at initialization time, even though some of them may never be used. A request queue is a large structure, since many (perhaps thousands) of request structures are allocated when the queue is initialized. A more clever implementation would allocate a request queue when needed in either the open method or the queue function. We chose a simpler implementation for sbull in order to avoid complicating the code.

Doing Without the Request Queue

 void blk_queue_make_request(request_queue_t *queue, make_request_fn *func); 

The make_request_fn type, in turn, is defined as follows:

 typedef int (make_request_fn) (request_queue_t *q, int rw,               struct buffer_head *bh); 

The phrase "arrange to transfer'' was chosen carefully; often a driver-specific make request function will not actually transfer the data. Consider a RAID device. What the function really needs to do is to map the I/O operation onto one of its constituent devices, then invoke that device's driver to actually do the work. This mapping is done by setting the b_rdev member of the buffer_head structure to the number of the "real'' device that will do the transfer, then signaling that the block still needs to be written by returning a nonzero value.

When the kernel sees a nonzero return value from the make request function, it concludes that the job is not done and will try again. But first it will look up the make request function for the device indicated in the b_rdev field. Thus, in the RAID case, the RAID driver's "make request'' function will not be called again; instead, the kernel will pass the block to the appropriate function for the underlying device.

sbull, at initialization time, sets up its make request function as follows:

  if (noqueue)     blk_queue_make_request(BLK_DEFAULT_QUEUE(major), sbull_make_request); 

It does not call blk_init_queue when operating in this mode, because the request queue will not be used.

When the kernel generates a request for an sbull device, it will call sbull_make_request, which is as follows:

  int sbull_make_request(request_queue_t *queue, int rw,                         struct buffer_head *bh) {     u8 *ptr;      /* Figure out what we are doing */     Sbull_Dev *device = sbull_devices + MINOR(bh->b_rdev);     ptr = device->data + bh->b_rsector * sbull_hardsect;      /* Paranoid check; this apparently can really happen */     if (ptr + bh->b_size > device->data + sbull_blksize*sbull_size) {         static int count = 0;         if (count++ < 5)             printk(KERN_WARNING "sbull: request past end of device\n");         bh->b_end_io(bh, 0);         return 0;     }      /* This could be a high-memory buffer; shift it down */ #if CONFIG_HIGHMEM     bh = create_bounce(rw, bh); #endif      /* Do the transfer */     switch(rw) {     case READ:     case READA:  /* Read ahead */         memcpy(bh->b_data, ptr, bh->b_size); /* from sbull to buffer */         bh->b_end_io(bh, 1);         break;     case WRITE:         refile_buffer(bh);         memcpy(ptr, bh->b_data, bh->b_size); /* from buffer to sbull */         mark_buffer_uptodate(bh, 1);         bh->b_end_io(bh, 1);         break;     default:         /* can't happen */         bh->b_end_io(bh, 0);         break;     }      /* Nonzero return means we're done */     return 0; } 

For the most part, this code should look familiar. It contains the usual calculations to determine where the block lives within the sbull device and uses memcpy to perform the operation. Because the operation completes immediately, it is able to call bh->b_end_io to indicate the completion of the operation, and it returns 0 to the kernel.

This interface may seem a little strange; it is done this way for two reasons. First is that the open method can still be called normally by a process that accesses the device directly -- the mkfs utility, for example. The other reason is a historical artifact: block devices once used the same file_operations structure as char devices, and thus had to conform to the same interface.

Other than the limitations on the arguments to the open method, the driver does not really see anything unusual when a filesystem is mounted. The device is opened, and then the request method is invoked to transfer blocks back and forth. The driver cannot really tell the difference between operations that happen in response to an individual process (such as fsck) and those that originate in the filesystem layers of the kernel.

  int sbull_release (struct inode *inode, struct file *filp) {     Sbull_Dev *dev = sbull_devices + MINOR(inode->i_rdev);      spin_lock(&dev->lock);     dev->usage--;     MOD_DEC_USE_COUNT;     spin_unlock(&dev->lock);     return 0; } 

Other driver functions are not affected by the "missing filp'' problem because they aren't involved with mounted filesystems. For example, ioctl is issued only by processes that explicitly open the device.

The HDIO_GETGEO command is the most commonly used of a series of HDIO_ commands, all defined in <linux/hdreg.h>. The interested reader can look in ide.c and hd.c for more information about these commands.

The sbull device supports only the general commands just listed, because implementing device-specific commands is no different from the implementation of commands for char drivers. The ioctl implementation for sbull is as follows:

  int sbull_ioctl (struct inode *inode, struct file *filp,                  unsigned int cmd, unsigned long arg) {     int err;     long size;     struct hd_geometry geo;      PDEBUG("ioctl 0x%x 0x%lx\n", cmd, arg);     switch(cmd) {        case BLKGETSIZE:         /* Return the device size, expressed in sectors */         if (!arg) return -EINVAL; /* NULL pointer: not valid */         err = ! access_ok (VERIFY_WRITE, arg, sizeof(long));         if (err) return -EFAULT;         size = blksize*sbull_sizes[MINOR(inode->i_rdev)] 		/ sbull_hardsects[MINOR(inode->i_rdev)]; 	if (copy_to_user((long *) arg, &size, sizeof (long))) 	    return -EFAULT;         return 0;        case BLKRRPART: /* reread partition table: can't do it */         return -ENOTTY;        case HDIO_GETGEO:         /* 	 * Get geometry: since we are a virtual device, we have to make 	 * up something plausible. So we claim 16 sectors, four heads, 	 * and calculate the corresponding number of cylinders. We set 	 * the start of data at sector four.          */         err = ! access_ok(VERIFY_WRITE, arg, sizeof(geo));         if (err) return -EFAULT;         size = sbull_size * blksize / sbull_hardsect;         geo.cylinders = (size & ~0x3f) >> 6; 	geo.heads = 4; 	geo.sectors = 16; 	geo.start = 4; 	if (copy_to_user((void *) arg, &geo, sizeof(geo))) 	    return -EFAULT;         return 0;        default:         /*          * For ioctls we don't understand, let the block layer          * handle them.          */         return blk_ioctl(inode->i_rdev, cmd, arg);     }      return -ENOTTY; /* unknown command */ } 

The operations in question are check_media_changeand revalidate. The former is used to find out if the device has changed since the last access, and the latter re-initializes the driver's status after a disk change.

As far as sbull is concerned, the data area associated with a device is released half a minute after its usage count drops to zero. Leaving the device unmounted (or closed) long enough simulates a disk change, and the next access to the device allocates a new memory area.

This kind of "timely expiration'' is implemented using a kernel timer.

check_media_change

It's interesting to note that when the device is removable but there is no way to know if it changed, returning 1 is a safe choice. This is the behavior of the IDE driver when dealing with removable disks.

The implementation in sbull returns 1 if the device has already been removed from memory due to the timer expiration, and 0 if the data is still valid. If debugging is enabled, it also prints a message to the system logger; the user can thus verify when the method is called by the kernel.

  int sbull_check_change(kdev_t i_rdev) {     int minor = MINOR(i_rdev);     Sbull_Dev *dev = sbull_devices + minor;      PDEBUG("check_change for dev %i\n",minor);     if (dev->data)         return 0; /* still valid */     return 1; /* expired */ } 

Revalidation

The action performed by revalidate is device specific, but revalidate usually updates the internal status information to reflect the new device.

In sbull, the revalidate method tries to allocate a new data area if there is not already a valid area.

  int sbull_revalidate(kdev_t i_rdev) {     Sbull_Dev *dev = sbull_devices + MINOR(i_rdev);      PDEBUG("revalidate for dev %i\n",MINOR(i_rdev));     if (dev->data)         return 0;     dev->data = vmalloc(dev->size);     if (!dev->data)         return -ENOMEM;     return 0; } 

Extra Care

 int check_disk_change(kdev_t dev); 

Some programs, however, directly access disk data without mounting the device: fsck, mcopy, and fdiskare examples of such programs. If the driver keeps status information about removable devices in memory, it should call the kernel check_disk_change function when the device is first opened. This function uses the driver methods (check_media_change and revalidate), so nothing special has to be implemented in open itself.

Here is the sbull implementation of open, which takes care of the case in which there's been a disk change:

  int sbull_open (struct inode *inode, struct file *filp) {     Sbull_Dev *dev; /* device information */     int num = MINOR(inode->i_rdev);      if (num >= sbull_devs) return -ENODEV;     dev = sbull_devices + num;      spin_lock(&dev->lock);     /* revalidate on first open and fail if no data is there */     if (!dev->usage) {         check_disk_change(inode->i_rdev);         if (!dev->data)         {             spin_unlock (&dev->lock);             return -ENOMEM;         }     }     dev->usage++;     spin_unlock(&dev->lock);     MOD_INC_USE_COUNT;     return 0;          /* success */ } 

To be able to support partitions on a device, we must assign several minor numbers to each physical device. One number is used to access the whole device (for example, /dev/hda), and the others are used to access the various partitions (such as /dev/hda1). Since fdisk creates partition names by adding a numerical suffix to the whole-disk device name, we'll follow the same naming convention in the spull driver.

  #define MAJOR_NR spull_major /* force definitions on in blk.h */ int spull_major; /* must be declared before including blk.h */  #define SPULL_SHIFT 4                         /* max 16 partitions  */ #define SPULL_MAXNRDEV 4                      /* max 4 device units */ #define DEVICE_NR(device) (MINOR(device)>>SPULL_SHIFT) #define DEVICE_NAME "pd"                      /* name for messaging */ 

The spull driver also hardwires the value of the hard-sector size in order to simplify the code:

  #define SPULL_HARDSECT 512  /* 512-byte hardware sectors */ 

The Generic Hard Disk

This decoding isn't easy, but fortunately the kernel offers "generic hard disk'' support usable by all block drivers. Such support considerably reduces the amount of code needed in the driver for handling partitions. Another advantage of the generic support is that the driver writer doesn't need to understand how the partitioning is done, and new partitioning schemes can be supported in the kernel without requiring changes to driver code.

Before we go further, let's look at some of the fields in struct gendisk. You'll need to understand them in order to exploit generic device support.

Many of the fields in the gendisk structure are set up at initialization time, so the compile-time setup is relatively simple:

  struct gendisk spull_gendisk = {     major:              0,            /* Major number assigned later */     major_name:         "pd",         /* Name of the major device */     minor_shift:        SPULL_SHIFT,  /* Shift to get device number */     max_p:              1 << SPULL_SHIFT, /* Number of partitions */     fops:               &spull_bdops, /* Block dev operations */ /* everything else is dynamic */ }; 

Partition Detection

  spull_sizes = kmalloc( (spull_devs << SPULL_SHIFT) * sizeof(int),                       GFP_KERNEL); if (!spull_sizes)     goto fail_malloc;  /* Start with zero-sized partitions, and correctly sized units */ memset(spull_sizes, 0, (spull_devs << SPULL_SHIFT) * sizeof(int)); for (i=0; i< spull_devs; i++)     spull_sizes[i<<SPULL_SHIFT] = spull_size; blk_size[MAJOR_NR] = spull_gendisk.sizes = spull_sizes;  /* Allocate the partitions array. */ spull_partitions = kmalloc( (spull_devs << SPULL_SHIFT) *                            sizeof(struct hd_struct), GFP_KERNEL); if (!spull_partitions)     goto fail_malloc;  memset(spull_partitions, 0, (spull_devs << SPULL_SHIFT) *        sizeof(struct hd_struct)); /* fill in whole-disk entries */ for (i=0; i < spull_devs; i++)      spull_partitions[i << SPULL_SHIFT].nr_sects =         spull_size*(blksize/SPULL_HARDSECT); spull_gendisk.part = spull_partitions; spull_gendisk.nr_real = spull_devs; 

  spull_gendisk.next = gendisk_head; gendisk_head = &spull_gendisk;  

 register_disk(struct gendisk *gd, int drive, unsigned minors,               struct block_device_operations *ops, long size); 

Here, gd is the gendisk structure that we built earlier, drive is the device number, minors is the number of partitions supported, ops is the block_device_operations structure for the driver, and size is the size of the device in sectors.

spull sets up partitions in the revalidate method:

  int spull_revalidate(kdev_t i_rdev) {   /* first partition, # of partitions */   int part1 = (DEVICE_NR(i_rdev) << SPULL_SHIFT) + 1;   int npart = (1 << SPULL_SHIFT) -1;    /* first clear old partition information */   memset(spull_gendisk.sizes+part1, 0, npart*sizeof(int));   memset(spull_gendisk.part +part1, 0, npart*sizeof(struct hd_struct));   spull_gendisk.part[DEVICE_NR(i_rdev) << SPULL_SHIFT].nr_sects =           spull_size << 1;    /* then fill new info */   printk(KERN_INFO "Spull partition check: (%d) ", DEVICE_NR(i_rdev));   register_disk(&spull_gendisk, i_rdev, SPULL_MAXNRDEV, &spull_bdops,                   spull_size << 1);   return 0; } 

 printk(" %s", disk_name(hd, minor, buf)); 

That's why spull prints a leading string. It's meant to add some context to the information that gets stuffed into the system log.

  for (i = 0; i < (spull_devs << SPULL_SHIFT); i++)     fsync_dev(MKDEV(spull_major, i)); /* flush the devices */ blk_cleanup_queue(BLK_DEFAULT_QUEUE(major)); read_ahead[major] = 0; kfree(blk_size[major]); /* which is gendisk->sizes as well */ blk_size[major] = NULL; kfree(spull_gendisk.part); kfree(blksize_size[major]); blksize_size[major] = NULL; 

  for (gdp = &gendisk_head; *gdp; gdp = &((*gdp)->next))     if (*gdp == &spull_gendisk) {         *gdp = (*gdp)->next;         break;     } 

Partition Detection Using initrd

When you boot a kernel with initrd, it establishes a temporary running environment before it mounts the real root filesystem. Modules are usually loaded from within the RAM disk being used as the temporary root file system.

Because the initrd process is run after all boot-time initialization is complete (but before the real root filesystem has been mounted), there's no difference between loading a normal module and loading one living in the initrd RAM disk. If a driver can be correctly loaded and used as a module, all Linux distributions that have initrd available can include the driver on their installation disks without requiring you to hack in the kernel source.

The Device Methods for spull

Here we will show how spull makes use of that information. The following code includes only those parts of spull that differ from sbull, because most of the code is exactly the same.

  Spull_Dev *dev = spull_devices + DEVICE_NR(inode->i_rdev); 

   case BLKGETSIZE:    /* Return the device size, expressed in sectors */    err = ! access_ok (VERIFY_WRITE, arg, sizeof(long));    if (err) return -EFAULT;    size = spull_gendisk.part[MINOR(inode->i_rdev)].nr_sects;    if (copy_to_user((long *) arg, &size, sizeof (long)))    return -EFAULT;    return 0; 

   case BLKRRPART: /* re-read partition table */    return spull_revalidate(inode->i_rdev); 

Here are the relevant lines in spull_request:

  ptr = device->data +       (spull_partitions[minor].start_sect + req->sector)*SPULL_HARDSECT; size = req->current_nr_sectors*SPULL_HARDSECT; /*  * Make sure that the transfer fits within the device.  */ if (req->sector + req->current_nr_sectors >                 spull_partitions[minor].nr_sects) {     static int count = 0;     if (count++ < 5)       printk(KERN_WARNING "spull: request past end of partition\n");     return 0; } 

Neither sbull nor spull can transfer data without using the system microprocessor; however, spull is equipped with the capability of simulating interrupt-driven operation if the user specifies the irq=1 option at load time. When irq is not 0, the driver uses a kernel timer to delay fulfillment of the current request. The length of the delay is the value of irq: the greater the value, the longer the delay.

  void spull_irqdriven_request(request_queue_t *q) {     Spull_Dev *device;     int status;     long flags;      /* If we are already processing requests, don't do any more now. */     if (spull_busy)             return;      while(1) {         INIT_REQUEST;  /* returns when queue is empty */          /* Which "device" are we using? */         device = spull_locate_device (CURRENT);         if (device == NULL) {             end_request(0);             continue;         } 	spin_lock_irqsave(&device->lock, flags); 	         /* Perform the transfer and clean up. */         status = spull_transfer(device, CURRENT);         spin_unlock_irqrestore(&device->lock, flags);         /* ... and wait for the timer to expire -- no end_request(1) */         spull_timer.expires = jiffies + spull_irq;         add_timer(&spull_timer);         spull_busy = 1;         return;     } } 

New requests can accumulate while the device is dealing with the current one. Because reentrant calls are almost guaranteed in this scenario, the request function sets a spull_busy flag so that only one transfer happens at any given time. Since the entire function runs with the io_request_lock held (the kernel, remember, obtains this lock before calling the request function), there is no need for particular care in testing and setting the busy flag. Otherwise, an atomic_t item should have been used instead of an int variable in order to avoid race conditions.

The interrupt handler has a couple of tasks to perform. First, of course, it must check the status of the outstanding transfer and clean up the request. Then, if there are further requests to be processed, the interrupt handler is responsible for getting the next one started. To avoid code duplication, the handler usually just calls the request function to start the next transfer. Remember that the request function expects the caller to hold the io_request_lock, so the interrupt handler will have to obtain it. The end_request function also requires this lock, of course.

In our sample module, the role of the interrupt handler is performed by the function invoked when the timer expires. That function calls end_request and schedules the next data transfer by calling the request function. In the interest of code simplicity, the spull interrupt handler performs all this work at "interrupt'' time; a real driver would almost certainly defer much of this work and run it from a task queue or tasklet.

  /* this is invoked when the timer expires */ void spull_interrupt(unsigned long unused) {     unsigned long flags      spin_lock_irqsave(&io_request_lock, flags);     end_request(1);    /* This request is done - we always succeed */      spull_busy = 0;  /* We have io_request_lock, no request conflict */     if (! QUEUE_EMPTY) /* more of them? */         spull_irqdriven_request(NULL);  /* Start the next transfer */     spin_unlock_irqrestore(&io_request_lock, flags); } 

  struct file_operations sbull_bdops = {     read:       block_read,     write:      block_write,     ioctl:      sbull_ioctl,     open:       sbull_open,     release:    sbull_release,     fsync:      block_fsync,     check_media_change: sbull_check_change,     revalidate: sbull_revalidate }; 

Note that block drivers are subject to the same changes in the file_operations prototypes between 2.0 and 2.2 as char drivers.

 blk_dev[major].request_fn = sbull_request; 

Because this method allows for only one queue per major number, the multiqueue capability of 2.4 kernels is not present in earlier releases. Because there was only one queue, the request function did not need the queue as an argument, so it took none. Its prototype was as follows:

 void (*request) (void); 

Also, all queues had active heads, so blk_queue_headactive did not exist.

  #ifdef RO_IOCTLS static inline int blk_ioctl(kdev_t dev, unsigned int cmd,                             unsigned long arg) {     int err;      switch (cmd) {       case BLKRAGET: /* return the read-ahead value */         if (!arg)  return -EINVAL;         err = ! access_ok(VERIFY_WRITE, arg, sizeof(long));         if (err) return -EFAULT;         PUT_USER(read_ahead[MAJOR(dev)],(long *) arg);         return 0;        case BLKRASET: /* set the read-ahead value */         if (!capable(CAP_SYS_ADMIN)) return -EACCES;         if (arg > 0xff) return -EINVAL; /* limit it */         read_ahead[MAJOR(dev)] = arg;         return 0;        case BLKFLSBUF: /* flush */         if (! capable(CAP_SYS_ADMIN)) return -EACCES; /* only root */         fsync_dev(dev);         invalidate_buffers(dev);         return 0;          RO_IOCTLS(dev, arg);     }     return -ENOTTY; } #endif  /* RO_IOCTLS */ 

The BLKFRAGET, BLKFRASET, BLKSECTGET, BLKSECTSET, BLKELVGET, and BLKELVSET commands were added with Linux 2.2, and BLKPG was added in 2.4.

 resetup_one_dev(struct gendisk *gd, int drive); 

register_disk is emulated in sysdep.h with the following code:

  static inline void register_disk(struct gendisk *gdev, kdev_t dev,                 unsigned minors, struct file_operations *ops, long size) {     if (! gdev)         return;     resetup_one_dev(gdev, MINOR(dev) >> gdev->minor_shift); }