UML and Device drivers

UML and Device drivers

I got the impression after reading numerous books and articles about device drivers that UML is almost never used in describing kernel and device driver design and architecture.Everything is described either by words or using proprietary notations. If you don’t knowabout UML(Unified Modeling Language) it is time to learnbecauseit isan industry standard general purpose modeling language with graphical notation. You can find many good tutorials on the Web and I can recommendthe book to start:

UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition

Recently I created some diagrams based on my past experience in using UML to describe and communicate architecture and design:

0. Component diagram depicting major driver interfaces

1. Class and object diagram depicting relationship between drivers and devices

2. Component diagram showing dependencies and interfaces when calling Win32 API function ReadFile

3. Component diagram showing IRP flow in a driver stack (driver-to-driver communication)

Actually I foundthat some driver books incorrectly depict the ordering of I/O stack locations in IRP stack correspondingtodriver or devicestack.The correct layout is depicted above. IRP I/O stack locations grow down (to lower addresses) in memory like any other Wintel stack. You can see it from kernel dumps or the following macro from DDK header file wdm.h which shows that next IRP I/O stack location is down in memory (1 is subtracted from current stack location pointer):

#define IoGetNextIrpStackLocation( Irp ) (
(Irp)->Tail.Overlay.CurrentStackLocation - 1 )

Dumps (and live debugging) are good in studying component relationships, reconstructing sequence diagrams, etc.For example, this edited fragment below is from crash dump and it shows who calls whom and component dependencies be reconstructed from call stackof Win32 API function GetDriveType: SHELL32 (calls it) -> kernel32 -> ntdll -> nt (ntoskrnl.exe). You can also see various Citrix hooks and filters here (CtxSbxXXX):

kd> kL
CtxSbx!xxx
nt!IovCallDriver
nt!IofCallDriver
CtxAltStr!xxx
nt!IovCallDriver
nt!IofCallDriver
nt!IopParseDevice
nt!ObpLookupObjectName
nt!ObOpenObjectByName
nt!IopCreateFile
nt!IoCreateFile
nt!NtOpenFile
nt!KiSystemService
SharedUserData!SystemCallStub
ntdll!ZwOpenFile
CtxSbxHook!xxx
kernel32!GetDriveTypeW
SHELL32!CMountPoint::_EnumMountPoints

- Dmitry Vostokov -