06ddBlkDrv

Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-1

Chapter

6

Writing Block Drivers

• How block drivers are integrated into the I/O system

• Block driver entry points.

• Supporting multiple partitions on a physical disk.

• Managing removable media.



6.1 Introduction

Block Drivers

• Definition of a block driver.

• How block drivers differ from character drivers.

• How the file system libraries connect to block drivers.

• Overview of DOS and raw file systems.


Definition of Block Device

• File-structured device such as hard or floppy disk drive.

• Random access capability.

• Data transferred only in multi-byte blocks.


Block Device Overview

Ap

pli

cati

on

I/O System

opencreatreadwriteioctlclosedelete

Devices

A

B

C

D

Blo

ckD

riv

ers

No

n-B

lock

Dri

ver

s

File Systems

DOS

------

Raw

• I/O System calls (open, close, etc.) map directly to file system routines,

not to driver routines.

• The file system makes calls to the block driver.

This diagram was shown earlier. The point is to remind the studentsabout the difference between character and block drivers by buildingon what they have already learned.


Overview of DOS File System

• Compatible with MS-DOS through version 6.2

• Hierarchical file system

• Uses disk space efficiently by not requiring files to be

contiguous (default)

• Optionally, permits creation of contiguous files for

faster access

• Uses restrictive 8+3 file names (default) with the option

of using UNIX style file names

• Avoid using the RT-11 file system, as the DOS file system is more flexible

and tends to be faster.

• To create a contiguous file, use the FIOCONTIG ioctl command.

• To use UNIX style file naming, see the section “Using Extended File

Names” in the dosFsLib manual pages. Using this option makes the file

system no longer DOS compatible.


Overview of Raw File System

• Handles entire logical disk (partition) as one file

• No directories or other organizational structure

imposed on disk

• Fastest access


File System Configuration

• Initialize the block driver

xxDrv();

• Create the logical disk (partition)

pBlkDev = xxDevCreate (..);

• Initialize a DOS file system

● New file systemdosFsMkfsOptionsSet (options); /* if needed */dosFsMkfs (fsName, pBlkDev);

— or —dosFsConfigInit (pConfig, ...);dosFsDevInit (fsName, pBlkDev, pConfig);fd = open (fsName, O_RDWR, 0);ioctl (fd, DISKINIT, 0);close (fd);

• The dosFsMkfs( ) routine creates a file system with default parameters.

Use dosFsDevInit( ) with an ioctl( ) FIODISKINT command to control

parameters yourself.

• The dosFsConfigInit( ) routine initializes a DOS_VOL_CONFIG structure,

pConfig in the example above. The structure may also be initialized

directly.

• The dosFsMkfsOptionsSet( ) is optional. It allows setting VxWorks-

specific options when creating file systems with dosFsMkfs( ).


Configuration (cont’d)

● Existing file systempVolDesc = dosFsDevInit (fsName, pBlkDev,

NULL);/* Set volatile options, if needed */dosFsVolOptionsSet (pVolDesc, options);

• Initialize a Raw file system:

rawFsDevInit (fsName, pBlkDev);

• Using dosFsDevInit( ) with a NULL third argument, causes the volume

configuration to be read from the file system existing on the disk.

• The dosFsVolOptionsSet( ) above is optional. It allows setting VxWorks

options which are not stored on disk such as DOS_OPT_CHANGENOWARN

and DOS_OPT_AUTOSYNC.


Data Integrity

• dosFsLib buffers FAT and directory information for

efficiency.

• To flush buffers use:

● dosFsVolUnmount( )● the FIOFLUSH ioctl command

● the DOS_OPT_AUTOSYNC flag

• For removable media, consider setting the

DOS_OPT_CHANGENOWARN flag

• FAT (File Allocation Table) is the data structure used by DOS to manage

disk blocks.

• The DOS_OPT_AUTOSYNC and DOS_OPT_CHANGENOWARN flags are set by

bitwise ORing them into the dosvc_options field of the DOS_VOL_CONFIG

structure.

• The DOS_OPT_CHANGENOWARN flag:

● Remounts the volume on each open( ) or creat( )● Sets the DOS_OPT_AUTOSYNC flag


Block Driver Overview

DOS

RawDOS

Raw

File Systems DriversDrivers

DOS A

B

DOS

Raw

• A driver may support multiple devices.

• Multiple file systems may reside on a single physical device.

• Driver has no information about file systems on the device.

• See the “Local File Systems” of the Programmer’s Guide for additional

information.


Opening A File On A Block Device

creat delete open close read write ioctl

0

1

2

dosFsCreate dosFsOpendosFsDelete dosFsClose

dosFsOpen (pDevHdr, “/myFile”,O_READ, 0)

Device List

Driver Table

"/dos"1

dosFsRead dosFsWrite dosFsIoctl

open (“/dos/myFile”, O_READ, 0)

• Application calls for block devices invoke file system routines directly,

not driver routines. The driver may or may not be called at all.

• There is no block driver open routine.

• The dosFsLib routines may make calls to the driver, including:

● xxStatusChk( ) routine (if provided)

● xxBlkRd( ) when a new open on removable media that has changed

• The xxStatusChk( ) and xxBlkRd( ) will be discussed later.


Reading From A Block Device

File Descriptor

Driver Table

dosFsRead (devId, &buf, nBytes)

read (fd, &buf, nBytes)

Table

creat delete open close read write ioctl

0

1

2

dosFsCreate dosFsOpendosFsDelete dosFsClose dosFsRead dosFsWrite dosFsIoctl

xxBlkRd (pBlkDev, startBlk, nBlks, pBuf)

• The block driver’s read routine is called by the file system.

• Note that the request is specified in blocks, not bytes.

• The xxBlkRd( ) routine will be discussed in detail later.



Introduction

6.2 Block Drivers

• Block driver initialization.

• The BLK_DEV structure.

• Block driver entry points.


Difference from Character Drivers

• Driver’s entry points are not entered in driver table (file

system’s entry points entered).

• Driver’s device descriptor is not linked into device list

(file system’s descriptor linked into device list).

• Driver supports different entry points.

• Data transfers are counted in blocks, not bytes.


Block Driver Initialization

• STATUS xxDrv (args...)

• Allocates and initializes driver data structures, if any.

• Takes driver-dependent arguments.

• Does not call iosDrvInstall( ).

• Block drivers often have null xxDrv routines. E.g.:

STATUS fooDrv (void){return (OK);}


Block Device Creation

BLK_DEV * xxDevCreate (args...)

• Defines logical disk (partition).

• Takes driver-dependent arguments.

• Does not call iosDevAdd( ).

• Must return a pointer to a device descriptor for which

first member is a BLK_DEV structure or NULL on error.

• Must initialize members of the BLK_DEV structure.

• Major differences between block and character xxDevCreate( ):

● The first argument is not the device name.

● The block driver does not call iosDevAdd( ).● A character driver returns STATUS; a block driver returns a pointer to

a BLK_DEV structure.

The file system is responsible for adding the device descriptor to thedevice list. The file system’s xxDevInit() routine defines the logicaldevice’s name. The block driver’s xxDevCreate() is preparing apartition (which may be the entire disk) to hold a file system. Thepointer to a BLK_DEV structure returned is used by the file systemroutines to connect the file system to the physical partition.


BLK_DEV Structure

bd_blkRd Address of block driver’s read routine

bd_blkWrt Address of block driver’s write routine

bd_ioctl Address of block driver’s ioctl routine

bd_reset Address of block driver’s reset routine(optional)

bd_statusChk Address of block driver’s routine tocheck disk status (optional)

bd_removable TRUE if device uses removable media,otherwise FALSE

bd_nBlocks Size of partition in blocks

• The BLK_DEV structure serves the same role as the driver table does for

character drivers, i.e. provides the driver entry points.

• BLK_DEV structure is defined in blkIo.h.

• Read, write and ioctl routines are required in a block driver.

• Note that bd_nBlocks is the size of the partition, i.e. logical device, notthe physical device.

Discuss the reset and statusChk routines later.


BLK_DEV Structure (cont’d)

bd_bytesPerBlk Number of bytes per block

bd_blksPerTrack Number of blocks per track

bd_nHeads Number of heads

bd_retry Retry count for I/O errors

bd_mode Device mode: O_RDONLY or O_RDWR

bd_readyChanged Set to TRUE

• Include ioLib.h and blkIo.h

Discuss the readyChanged flag later.


Supporting Multiple Partitions

• To support multiple file systems on the same physical

device, you must save the partition offset.

• Example implementation:

typedef struct{BLK_DEV blkDev;int partitionOffset;} MY_DEV;

BLK_DEV * myDevCreate (int offset, int size, ...){...pMyDev->partitionOffset = offset;return (&pMyDev->blkDev);}

• The above code assumes that pMyDev is the address of a MY_DEV

structure.

• The partitionOffset must then be used by the xxBlkRd( ) and xxBlkWrt( )routines to perform I/O in the correct partition.

The number of blocks in the partition is part of the BLK_DEVstructure (bd_nBlocks).


Supporting Multiple Partitions

Request A1

A

B

Request A2

Request A3

Request B1

Request B2

Request B3

File System A Requests File System B Requests

Block Driver Requests

• Requests on the same file system are synchronous:

● Request A2 will not be made to the driver until A1 is completed

● Request A3 will not be made to the driver until A2 is completed

• Requests from different file systems are asynchronous:

● Request B1 may occur before, during or after A1.

● Request B2 may occur before, during or after A1 (but it will onlyoccur after B1 is completed)

• Typically, block drivers either:

● Use mutex semaphores to insure exclusive access, or

● Allow only one partition on a physical device


Block Read/Write Routines

STATUS xxBlkRd (pDev, startBlk, nBlks,pBuf)

STATUS xxBlkWrt (pDev, startBlk, nBlks,pBuf)

pDev Pointer to BLK_DEV structure

startBlk Block number to begin reading orwriting

nBlks Number of blocks to read or write

pBuf Pointer to buffer to put data read orget data to write

• Must supply a xxBlkWrt( ) routine. For read-only devices, just return

ERROR.

• Must supply a xxBlkRd( ) routine. For write-only devices, just return

ERROR.

• If you are supporting multiple file systems on the same device,

remember that the startBlk is relative to the beginning of the partition

(logical disk, not physical).

• The first block is block number zero (not one).


Block Ioctl Routine

int xxIoctl (pBlkDev, cmd, arg)

• Same as non-block driver ioctl( ).

• If cmd is not recognized by the file system, the driver’s

xxIoctl( ) is called.

• Unknown cmd’s should be failed by setting errno to

S_ioLib_UNKNOWN_REQUEST and returning ERROR.

ioctl ( ) dosFsIoctl ( ) xxIoctl ( )

Application File System Driver

• An xxIoctl( ) must be supplied, even if it does nothing but fail requests

as above.

• The ioctl commands supported by dosFsLib and rawFsLib are

documented in the respective man pages.

• The driver’s ioctl commands should be defined to be numbers above

0x1000 to avoid conflicts with the file system ioctl commands.


Block Reset Routine

STATUS xxReset (pBlkDev)

• If provided, called by file system library when:

● File system is first mounted on device.

● After a failed read or write and before a retry.

• Return STATUS.

• Note that a driver may control more than one device. Only the device in

question (identified by pBlkDev) should be reset when this routine is

called.

• The xxReset( ) routine is optional.


Block Status-Check Routine

STATUS xxStatusChk (pBlkDev)

• Called by file system for each open( ) or creat( ) on the

device.

• Should return STATUS:

● If ERROR returned, open( ) will fail.

● When failing a request set errno to indicate reason.

• Purpose is to handle removable media:

● If media changed, set bd_readyChanged to TRUE.

● Return OK.

• Another use of xxStatusChk( ) is to check for write-protected media. If

write-protected, set bd_mode to O_RDONLY.

Setting bd_readyChanged is equivalent to executing either: the filesystem ready-change routine, e.g. dosFsReadyChanged(), or the filesystem’s ioctl() with the FIODISKCHANGE command. It remountsthe file system.

This routine was designed to handle removable media. An example ofwhy you might want to fail a xxStatusChk() call is if no disk is in thedisk drive or your device is hung.

Modifying bd_mode lets the file system fail the open() if the userrequested O_WRONLY or O_RDWR access.


Handling Removable Media

• Whenever the driver identifies that the user has

changed media, the bd_readyChanged flag should be set

to TRUE.

• When the file system finds the flag set, it remounts the

file system.

• The driver should never reset bd_readyChanged.


Summary

• Block driver initialization

● xxDrv( )● xxDevCreate( ) — returns a BLK_DEV pointer

Do not install driver in driver table or add device to thedevice list.

• Block driver entry points

● xxBlkRd( )● xxBlkWrt( )● xxIoctl( )● xxReset( )● xxStatusChk( )


Summary

• Supporting partitions

● Store partition offset in device descriptor

● In xxBlkRd and xxBlkWrt routines, add the partitionoffset to the start block to determine region to read orwrite

• Removable Media

● Write a xxStatusChk routine

● Set bd_readyChanged field in the BLK_DEV structurewhen media has changed

● Update bd_mode to O_RDONLY or O_RDWR

Documents

06ddBlkDrv