Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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..??
Distribution: Ubuntu 11.4,DD-WRT micro plus ssh,lfs-6.6,Fedora 15,Fedora 16
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.
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
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.
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.