In my last post I had posted a link to a *.tar.gz file containing the source code to both a very generic Linux RAM disk module that I wrote for the Linux 2.6.26.x kernel (was tested on Fedora 8 and Debian 5.0.1) and the source to a single purpose user binary that obtains the total device block count (no. of sectors) via an ioctl() and also performs some write(), lseek() and read() operations.This way, if the user were to monitor the /var/log/messages file they would see exactly where the process is in the driver code (I had placed many printk() messages for learning and tracking purposes).
I had made some updates to the device driver. The updates are so minor that the revision level of the driver incremented from 0.1 to 0.1.1. The updates are as follows:
- The user has the ability to specify a size (in MB) for the module during the module insertion.
- Also I added a second case field. The only one supported in v.0.1 was BLKGETSIZE which returned the total sectors for the default 64 MB size. As of v.0.1.1, the case statement now calculates from the specified size as opposed to the fixed value it was returning before. The new case field is BLKSSZGET which returns the sector size.
Shortly I will add support for later kernel revisions as the field for unlocked_ioctl() has been removed; at least from what I can tell when I view the block_device_operations structure in the include/linux/blkdev.h file of the source tree. Note that I am seeing this in the 2.6.28.x kernel (confirmed at lxr.linux.no). The block_device_operations structure was modified and relocated from include/linux/fs.h to the location specified above.
When monitoring the /var/log/messages, the user may notice that when invoking my test application (rxio), despite the fact that the application writes before it reads to/from the disk, the trace log will report the opposite (read then write). This is a result of the kernel scheduler. When a request (reference rx_request() function in the source code) is made to the block device for a read/write operation and multiple operations are sent to it, the first request to return is what the scheduler believes would be the best to execute next. So there is nothing wrong here and nothing to be concerned about.
To specify the RAM disk size during insertion, you will need to type the following, otherwise it will continue to default to 64 MB:
| # insmod rxd.ko sizemb=96 |
Version 0.1.1 can be downloaded from here. As I update this driver I will post the details on those updates.
