Next Page > Hide TOC

Introduction to Accessing Hardware From Applications

Contents:

Who Should Read This Document?
Organization of This Document
See Also


There are many reasons your application might need to access hardware: Receiving mouse and keyboard events, accessing devices, such as a FireWire DV camcorder, and driving a device from an application are just a few. Although only code that resides in the kernel can access hardware directly, Mac OS X provides many services that allow you to communicate with hardware from plug-ins, applications, shared libraries, and other code running outside the kernel.

Who Should Read This Document?

This document describes how software running in Mac OS X can access hardware by communicating with the kernel, focusing on services the I/O Kit provides to develop an application-based driver. You should read this document if you need to access a device from an application. Note that many applications will be able to handle all their hardware-access needs using high-level APIs, such as Open Transport and QuickTime, that are available through Carbon and Cocoa. To help you determine which approach is right for you, and for a summary of other services Mac OS X provides for hardware access from applications, see “Hardware-Access Options.”

This document includes many code fragments illustrating the various tasks involved in developing an application that accesses hardware, but it is not intended to be a step-by-step cookbook for accessing a particular type of device. To determine how to access a particular device, see “I/O Kit Family Device-Access Support”; For each device family it specifies how to access a device in that family and where to find more detailed documentation.

This document does not describe how to write kernel-resident code to access hardware. Kernel programmers should refer to Kernel Programming Guide and in-kernel device-driver developers should read I/O Kit Device Driver Design Guidelines. In particular, if you are developing your own device interface and user client to create a custom solution to access your device, you should read the “Making Hardware Accessible to Applications” chapter in that document. For other documents that cover how to access particular devices, visit Reference Library > Hardware & Drivers.

Organization of This Document

Accessing Hardware From Applications includes the following chapters:

See Also

Although this document includes a summary of basic I/O Kit information (in “I/O Kit Summary”), you should read I/O Kit Fundamentals for a thorough understanding of this subsystem.

Familiarity with the CFPlugIn architecture is useful in reading this document. This architecture is described in the developer documentation available in Reference Library > Core Foundation.

Knowledge of the Mac OS X kernel and device drivers may be useful but is not required. To get more information about these topics, visit Reference Library > Darwin.

When you install the Developer package, you get developer documentation as well as tools and example code. You can find all the I/O Kit and kernel documents mentioned in this document listed in /Developer/ADC Reference Library/documentation/Darwin and /Developer/ADC Reference Library/documentation/HardwareDrivers. Sample projects are available in /Developer/Examples. Most of the sample projects that are relevant to device access from applications reside in /Developer/Examples/IOKit.

There you can view the documentation for BSD and POSIX functions and tools by typing man function_name in a Terminal window (for example, man gdb) or in HTML at Mac OS X Man Pages.

You can access reference documentation on I/O Kit families from Xcode, Help Viewer, and Reference Library > Hardware & Drivers. Of course, you can also browse the header files for various I/O Kit families and other I/O Kit services accessible from user space in /System/Library/Frameworks/IOKit.framework/Headers.



Next Page > Hide TOC


© 2001, 2007 Apple Inc. All Rights Reserved. (Last updated: 2007-02-08)


Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.