Hi there,

i would like to understand a bit better about how linux treat a piece of hardware as a file and why ?? What is the benefit of treating a hardware as a file?From this files what kind of useful info can you extract and how to do that..??

not just Linux, but all *NIX operating systems treat hardware like a file. The how is that the driver creates a special file called a device node that appears in the /dev file-system. The why is if I recall correctly mostly to make things easier for programmers to access the devices since they can use standard file in/out methods rather then have to access the device drivers directly, at least that's what I remember being told by my instructor when I was taking an intro Linux course.

1 members found this post helpful.

Exactly. For example, to make a raw image of your disk, you don't need to write a program that calls the kernel. You can just use a normal command-line command that works on files.

1 members found this post helpful.

thanks for the info.it helps me a lot.And would you share some more info about the benefits of treating a device as a file ??

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.

1 members found this post helpful.

thanks a lot....