theNbomr |
05-28-2011 12:11 AM |
Well, if you turn the question around, you would ask "how else would you access a device"? The semantics of accessing devices which are abstracted as files just works well. For most devices, you need to make them do something, or more accurately, tell them to do something. This is a lot like writing to a file, so why not write to a device? Similarly, when you need to get some data or status information from a device, you ask it to give it to you by reading from the device.
For years, OSes defined a fairly standard API for access to files: open(), read(), write(), close(), and a few other calls. Since this API was already understood, and a lot of the underlying code and mechanisms could be shared between IO and the filesystem, I'm sure it just made sense to the creators of Unix to extend the metaphor to device access.
The concept does lend itself very nicely to extension of support for new or different hardware. The standard API is well known, so implementing drivers becomes easier. To fit a new driver into an existing architecture, you simply create a new device node in the filesystem, and and the underlying driver works in ways similar to all of the other drivers. Application code can then be written to use various types of devices according to run-time conditions, in contrast to hardwiring the application to a particular piece of hardware.
The concept of ownership and privilege borrowed from the filesystem can also be used to provide appropriate access to devices. I'm sure there are other good reasons, but these are probably the key issues.
--- rod.
|