Upload
mohammad-mohsen-amiri
View
8
Download
2
Embed Size (px)
Citation preview
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-2
Writing Block Drivers
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-3
Definition of Block Device
• File-structured device such as hard or floppy disk drive.
• Random access capability.
• Data transferred only in multi-byte blocks.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-4
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-5
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-6
Overview of Raw File System
• Handles entire logical disk (partition) as one file
• No directories or other organizational structure
imposed on disk
• Fastest access
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-7
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( ).
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-8
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-9
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
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-10
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-11
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-12
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-13
Writing Block Drivers
Introduction
6.2 Block Drivers
• Block driver initialization.
• The BLK_DEV structure.
• Block driver entry points.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-14
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-15
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);}
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-16
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-17
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-18
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-19
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).
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-20
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
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-21
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).
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-22
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-23
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-24
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-25
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.
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-26
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( )
Wind River SystemsTornado Device Driver Workshop © Copyright Wind River Systems 6-27
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