short paper - department of computer science.doc

By Donald Daniels,2014-10-15 15:26
8 views 0
short paper - department of computer science.doc

Creation of an Object Model and Object Oriented API for

    the Windows mLAN Driver

    Shaun Miles

    Computer Science Honours, Rhodes University

    Supervisor: Prof. R. Foss


This short paper is serves the purpose of exposing the inner-workings of the Windows music Local Area

    Network (mLAN) driver to aid in further research of the mLAN system. mLAN represents an innovative

    environment for networked high-speed transmission of real-time audio and MIDI streams. An exploration

    of the mLAN architecture and the Windows Driver Model gives us insight into the core concepts central

    to the creation of the mLAN driver. This understanding will be expressed by developing an object model

    of the mLAN driver.

    model of the mLAN driver. With this as a base to 1. Introduction

     understanding the structure of the mLAN driver, Prompt and on time delivery of data is the there will be a description of the nature of the IO cornerstone of any real-time system. In a Control (IOCTL) codes.

    professional environment, such as a music studio,

    the precise delivery of audio data dictates the The music Local Area Network (mLAN) 2.

    speed (and to an extent, the success) of the Architecture

    project. Legacy studios are an array of equipment

    and a mass of analogue and digital audio cables. Yamaha began developing a system to proved Configuring the studio becomes a task unto its single cable connections between the arrays of own, time consuming and complex. The standard audio studio equipment in an attempt to assortment of analogue and digital cables depends 1394 (Firewire) was chosen as the foundation on on the nature of the equipment used, representing top of which to build the mLAN system, for it a number of different formats of transmitting addressed the many aspects required of the audio and control data. mLAN provides a proposed system. The mLAN system can operate scalable high-performance real-time audio independently of a central server or a host network system, which allows the digital transfer controller, not requiring the use or the power of a of audio and control data. computer. Responsibility of management and

     control of the bus is automatic and falls to This short paper takes a brief look at the mLAN selected nodes on the bus. Using the computer as system and other topics relevant to development a tool to visually model the bus and to manage of a Windows Driver. A look at the concepts the connection of nodes extends the functionality inherent to the development of the mLAN system of the mLAN system.

    will take place in the next section. Exploring the

    underlying mLAN architecture will set the 2.1 IEEE 1394

    context for the mLAN driver. A brief summary of

    relevant concepts of the Windows Driver Model IEEE 1394 is a specification that defines a serial will help to give the needed background to bus architecture with a common set of core understand what the mLAN driver accomplishes. features that is an extension to the Control and This will all help in explaining a high-level object Status Registers (CSR) architecture [Anderson,

Page 1 of 6 Creation of an Object Model and Object Oriented API for the Windows mLAN Driver

    1999]. The CSR is a standard definition to permit chips [AE Notes, 2005]. The chips, ASICs easier implementation of software, and allows (Application Specific Integrated Chips), provide interoperability between Firewire on different an interface between the IEEE 1394 node and the platforms. It is based on the ISO/IEC 13213 studio equipment. They also control the transfer specification that standardises the offset locations bit-rate, the encapsulation and extraction of audio within the initial register address space. The CSR and MIDI data into sequences, and the specifies the arrangement of an addressable space construction of the Common Isochronous range containing data structures that identify the Protocol (CIP) packets. These CIP packets components of the bus, be it a bus, a bridge or a (comprising a CIP header and several CIP data node, the components state and other information. blocks) make up the payload data of the

     isochronous packets that in turn form the Features responsible for the usage of Firewire as isochronous streams. The CIP formatting is based the mLAN system are as follows: on the IEC 61883-1 specification for data flow

    and connection management [AE Notes, 2005]. ; High speed bus with scalable performance

    The payload of the CIP packet is the AM824 (8 The throughput speed of the bus satisfies

    bit label and 24 bit Audio/Music data) block the high bandwidth of any real-time audio

    format given by the IEC 61883-6 specification. processing system, allowing a network of

    The CIP header contains data that provides a many devices capable of transmitting and

    mechanism for synchronising the reassembly of receiving streams of audio data.

    the audio/music data. ; Plug and play support

     The bus orchestrates the automatic

    The isochronous packets are constructed by the configuration of newly added devices.

    IEEE 1394 node Link Layer. Packets are Each time a device is added or removed

    identified by a channel number that has a single the bus automatically re-enumerates itself,

    corresponding stream. Each packet within a forming a new bus topology. This is done

    stream comprises several data blocks, which are independently and without the

    made up of a number of quadlets (4-byte blocks) intervention of a host system.

    [AE Notes, 2005]. Sequences are designated by ; Eliminate host processor/memory bottleneck

    the series of quadlets corresponding to a position Processing any amount of multimedia data

    in each data block of that packet. Sequences and requires a robust system to handle the

    plugs are core to the functionality of the mLAN large and time-dependant flow of data. By

    system, in that each sequence is issued from an eliminating the need for a central server

    output plug and gathered by an input plug [AE the bus is free to automatically direct the

    Notes, 2005]. A plug is an abstraction formed by transfer of data between the devices,

    the Enabler, representing the input and output thereby removing a potential bottleneck.

    capabilities of the studio equipment. The Enabler This is supported by the use of peer-to-

    is software on the computer that interacts with the peer transactions

    Transporters (device-specific enumeration of the ; Support for Isochronous data streams

    plugs) and allows connection a management. It is Firewire provides support for isochronous

    the plugs that the studio equipment can send and packet streaming, satisfying the need for a

    receive data on the bus. constant transfer rate in an audio system.

     This is a high-priority transfer mode that

    A computer must have a driver to know how to guarantees delivery of data at constant

    interface to any attached hardware device. IEEE rate.

    1394 is a bus, such that each device on the bus is

    seen as a node. A host controller (the card that 2.2 The mLAN extension

    allows the computer to connect to the bus) must

    appear as a node in order for the computer to The mLAN system extends the IEEE 1394 CSR

    interact with the bus [McKenzie, 2003]. The architecture by implementing several different

    computer’s host controller must have an IEEE registers and by using a series of application level

Page 2 of 6 Creation of an Object Model and Object Oriented API for the Windows mLAN Driver

    1394 driver in order to interact with the computer. operations on underlying physical devices or Microsoft ships low level drivers for all the major busses connected to the device. Once again, the device and bus types for the vendor-supplied miniport driver is tailored for vendor specific drivers to make use of. These vendor drivers form operations. The hardware bus driver is supplied client drivers that provide access to the vendor by Microsoft and should not be replaced. specific functionality of the device. The Windows

    mLAN driver is a client Firewire driver that

    makes use of the Windows supplied IEEE 1394

    driver. The mLAN driver is able to manipulate

    the Unit Directory of the host controller via the

    underlying IEEE 1394 driver to make it appear as

    a mLAN device.

3. Windows Driver Model

The Windows Driver Model (WDM) is a

    framework for designing and developing drivers

    for NT based Windows platforms. WDM drivers

    have well-defined responsibilities in facilitating

    I/O operations for applications and other drivers

    [Oney, 1999].

The core concept of the WDM is the driver stack.

    According to Oney, the Windows operating

    system comes with base drivers that take care of

    generic I/O operations for standard hardware

    devices. In this architecture, a driver is supported

    by a chain of other drivers below it. The layered

    approach is such that at each level of the stack a

    driver in that stack has the opportunity to act on a

    request being sent down. If the driver cannot

    fulfil the request it will pass the request down the

    stack until the request can be satisfied. The results are then passed back up the stack and back to the

    application that made the request. This approach

    allows drivers to focus on a small area of

    functionality and specialisation [Oney, 2003].

     Figure 1: Layered Driver Architecture [MSDN, Figure 1 illustrates a hypothetical driver stack, 2005]

    showing the different types of drivers a stack

    could have. The kernel-mode client driver 3.1 Driver structure and the Operating System handles requests from an application via the

    Win32 API. The class driver, usually supplied by Within the kernel of the Windows operating Microsoft, provides the system-required but system there are components that monitor and hardware-independent support for a class of allocate system resources as they are required device. The miniclass driver is usually supplied [MSDN, 2005]. These components are by the hardware vendor to integrate any unique responsible for the running of the operating functionality their device may have. The port system. Figure 2 is a functional overview of a driver (or in some cases, the host controller or driver representing the three entry points into the host adapter driver) supplies required I/O driver. The kernel (actor) in the Use Case

Page 3 of 6 Creation of an Object Model and Object Oriented API for the Windows mLAN Driver

    diagram comprises the relevant components used the AddDevice routine of the driver. The driver in dealing with drivers. The use cases Manage requests system resources via a system call to Driver and Manage Devices encapsulate the create the device object and is returned a pointer specific functionality of the driver and to the newly created device object. The device enumerated devices. object is stored in the driver allocated memory

     space and is used as a means to interface with the


    3.2 Driver communication

    The last entry point routine is an IO Request

    Packet (IRP) dispatch routine. The IO manager

    communicates with the driver by issuing it IRPs.

    IRPs are essentially data structures that contain

    certain fields, defining the type of action to be

    performed. There are fields which allow for the

    transportation of data that is need in servicing the

    request. The results can be accessed via similar

    fields. Each IRP has an action defined by a

    function code. There are two types of function

    codes for an action. One is a major function code which indicates the main action, while the minor Figure 2: Driver Use Case Diagram [Oney, 2003]

    function code further specifies the action. The IRP is dispatched to IRP handler routines When the OS detects a new Plug and Play device depending on the function code. the PnP manager determines which drivers are required to support that device and loads those Any user-mode application must make use of the drivers [Cant, 1999]. Devices are identified by an WIN32 API to access the functionality of any electronic signature specifying the device ID and hardware device provided by its driver [MSDN, its Vendor. It is the PnP manager that enumerates 2005]. Applications can interact with a driver by all the OS attached devices. Kernel-mode drivers specifying a custom or a device-specific IO form part of the kernel, in that they occupy Control (IOCTL) code. The IOCTL codes expose allocated system memory and are represented the functionality of the driver (i.e. control over through the use of system created objects. The the device) to the application or the operating IO manager creates a driver object that represents system. The IO manager receives this request the driver. The driver object is assigned system from the application then builds and allocates memory for it to store driver related objects and memory for the IRP. The IRP is passed to the information, and becomes responsible for any relevant driver stack. The driver will have handler device it was loaded for. routines for the different IOCTL codes. It is the IO manager that is responsible for 4. Object Model for the mLAN Driver communicating with the driver and their devices [MSDN, 2005]. Every driver has WDM defined The Windows mLAN driver makes use of a entry points that the IO manager can call to proprietary Driver Development Environment communicate with the driver. A pointer to the called DriverStudio from Compuware. This driver object is passed to the driver as a parameter provides an object oriented driver framework that when it is loaded through a routine called conforms to and encapsulates the concepts DriverEntry. Any initialisation of the driver takes inherent in the WDM. The framework is a place here. Now that the driver is up and running collection of objects and classes that form a it is free to be acted upon by the OS. The newly foundation and a skeleton for the quick and detected device must be enumerated by calling

Page 4 of 6 Creation of an Object Model and Object Oriented API for the Windows mLAN Driver

    efficient development of a driver. The classes and DispatchFilter routine. An IRP is always directed objects are built specifically to closely model the to a targeted device object so the dispatch routine WDM architecture. The classes that driver writers will know where to send the IRP.

    use to derive their own classes for their drivers

    contain functionality and resources to allow for A device object is created from the class the integration of the driver into the framework. CmLanBus, derived from KDevice and

    The objects provide functionality to allow for the KPnpDevice. This object represents the

    ease of working with the data structures within functionality of the device by implementing the the driver context. The purpose of the framework IRP and IOCTL handler routines. It is within the is to provide a model for the communication IRP and IOCTL handler routines that the driver between the different components, which provides its core functionality. A driver can only encapsulates the flow of data required to facilitate respond to system initiated events, never on the functioning of the driver. It also reduces the accord of its own [MSDN, 2005]. A new device amount of general work that must done for any is created when it is detected and has an driver, and it handles the more mundane matters electronic signature that corresponds to those of writing a driver. This leaves the development specified by the driver’s INF file. Conforming to team to focus on the specific functionality they the WDM, the driver object keeps track of the wish to implement. device objects under its control. Furthermore, the

     device object must connect to the driver below it

    in the stack. This is achieved by using an

    abstraction of a “lower device” object which

    represents the target of further IO requests. In

    this case, the lower device object represents the

    IEEE 1394 driver that is responsible for access to

    the Firewire bus.

    The mLAN driver makes use of WDM Streaming

    Minidrivers to control and interpret the streams

    between the mLAN-node devices on the Firewire

    bus. The mLAN driver uses a minidriver to

    control an isochronous data stream between the

    nodes. This makes use of the Kernel Streaming

    architecture, which allows the processing of

    streaming data. The DriverStudio framework

    encapsulates the WDM Streaming architecture,

    allowing the classes to represent the streams and

     their respective adapters. These minidrivers fall Figure 3: Object Model of mLAN Bus Driver under the control of the mLAN bus driver.

    5. Object Oriented API for the IOCTL calls Figure 3 represents a high level overview of the

     mLAN driver within context of the DriverStudio

    The developer of an application has to have framework classes.

    knowledge of the IOCTL codes and the data

    structures it takes as parameters. It is unusual for The main bus driver is created from the

    the driver source code to be available to the CmLanBusDriver class by the PnP manager,

    public, and so access to the device is given derived from the KDriver class. CmLanBusDriver

    through an API that makes use of the IOCTL contains the entry routines to the driver code;

    codes. Through the creation of an object model of DriverEntry is called when the driver is first

    the mLAN driver, the understanding of the inner-loaded by the system, AddDevice is called when a

    workings of the driver is established. It is then new device is detected, and any IRP is sent to the

Page 5 of 6 Creation of an Object Model and Object Oriented API for the Windows mLAN Driver

    possible to modify or expose the IOCTL calls to a any computer technology, understanding the general API. This will allow the development of inner workings of the system is a prerequisite for

    applications to fully explore the nature of the insightful progress. By creating the object model

    mLAN system. of the Windows mLAN driver, it becomes

     possible to ascertain the functionality contained

    On the application side, a WIN32 API call within the IOCTL code handler routine. By DeviceIoControl is made, passing parameters (a implementing custom IOCTL codes and its handle to the device, the IOCTL code, and other handler routine, it becomes possible to extend the

    fields specifying the input/output buffers and file mLAN driver.

    access), and using the buffers to pass information

    pertinent to the IOCTL code. An API would

    abstract the IOCTL codes and take care of the 7. References

    ;necessary parameters. API’s are as useful as their

    [Anderson, 1999] Anderson, D. FireWire System documentation. This entails specifying the input ndArchitecture: IEEE1394a, 2 Edition, and output parameters, and the context of

    Mindshare Inc., Addison-Wesley, 1999 operation it represents.

    [AE Notes, 2005] Audio Engineering Course The IOCTL codes used by the mLAN driver are

    Notes, 2005 custom in their design, sporting function code

     enumerations within the custom range. mLAN’s

    [Cant, 1999] Cant, C. Writing Windows WDM implementations of these IOCTL codes span

    Device Drivers, R&D Books, Lawrence, 1999 different realms of usage. There are certain

     IOCTL codes in place for communication

    [DriverStudio, 2004] Compuware Corporation, between the driver and the mLAN WDM

    DriverStudio Version 3.2, 2004 Streaming minidrivers. Other codes refer to the

     underlying usage of the IEEE 1394 and IEC

    [McKenzie, 2003] McKenzie, B. 1394 Node-61883-6 drivers.

    Targeted Asynchronous Transfers [Online] 5.1 Intended Work

    1394NodeTransfers.htm, 2003

     In order to develop an API, complete

    [MSDN, 2005] Microsoft Developers Network documentation of the IOCTL codes must be done.

    (MSDN) Library, April 2005 This involves documenting the data structures

     used to store information relevant to handling of

    [Oney, 1999] Oney, W. Programming the the IOCTL. This in turn involves understanding

    Microsoft Windows Driver Model, Microsoft the purpose of the IOCTL, and excluding those

    Press, Washington, 1999 that are for the internal communication between

     drivers. This understanding will be portrayed

    [Oney, 2003] Oney, W. Programming the through the use of sequence diagrams. ndMicrosoft Windows Driver Model, 2 Edition, E-

    BOOK 2003 6. Conclusion

     In dealing with the IEEE 1394 bus architecture, it becomes immediately apparent about the

    correctness in the choice of the foundation for the mLAN system. Coupling high-performance and

    scalability, mLAN sets the basis for any real-time multimedia system to follow. To support that

    claim, further investigation into the potential of the mLAN system must be carried out. As with

    Page 6 of 6 Creation of an Object Model and Object Oriented API for the Windows mLAN Driver

Report this document

For any questions or suggestions please email