Originally Posted by
teryret
I haven't done much with hardware, but I have a few experiences that all seem to be quite different, I'm just trying to fit it all together in my head.
For example, if I wanted to use a PS3 controller to control a python script I would use Willow Garage's ps3joy "driver". It's written in python and takes data from a bluetooth connection, massages it, and sends it out to /dev/uinput (which I could look up how to read from). I'm sure that doing it this way has its pros and cons (but I don't know any of them). If instead of a PS3 controller I wanted to use a Space Pilot Pro I would instead use the spacenavd "driver" from the repos. I assume it's written in C++, but the curious thing about it is that it runs as a daemon (which I believe implies that it runs in user space), takes data from somewhere, massages it, and sends it outs to clients that connect either through X11(?) or an AF socket. I'm sure that doing it this way has its pros and cons as well (but again I couldn't name any). I've learned that "drivers" can also be compiled into the kernel, and they can be loaded in dynamically too (is this what modprobe does?). So that's four different ways of talking to hardware. Are there more? When might I choose one over another? With such significant amount of variety in things that call themselves drivers, would it be safe to say that driver is a less formal term than I first imagined?
The only reason I brought up Java is because I wanted an example of a language that a hardware consuming app might be written in that makes some of these four approaches of drivers harder to deal with than others. It's easy to open a file-like thing in java, but it's not easy to connect to an AF socket (for example).
You almost always talk to the hardware using entries under /dev.
There are no 4 ways that you talk about - the "driver" for the hardware always resides in the kernel - either as a loadable module or compiled into the kernel binary.
Loadable modules allow for:
o. smaller initial kernel binary
o. dynamically adding support for newer hardware
o. not loading drivers for hardware that you don't have
With drivers compiled into the kernel binary, you get:
o. no need to load drivers to activate/use the hardware - reducing dependencies
o. larger kernel binary
o. no way of removing code from kernel that may not be used (possibly, because h/w not present?)
Nowadays, most of the distros try to ship as much of the code as possible as loadable modules instead of built into the kernel binary. This allows them to remain very flexible and still support newer hardware without a full kernel recompile.
Now, how does the kernel understand which driver to use for which device?
It uses two magic nos. called major and minor nos.
If you look at the entries under /dev, you'd find it to look something like:
Code:
crw-rw-rw- 1 root root 1, 5 2012-08-16 08:54 /dev/zero
The nos. before the date in the above entry are the major and minor nos.
Each driver registers these nos. with the kernel (in short telling the kernel that "I'll handle all operations for the major no. x minor no. y").
This is as far as "drivers" are concerned.
However, how do you actually use these drivers from your application code?
Simple - by just opening the files under /dev using normal system calls like open(), read() and write() - like you'd use a normal file.
You may sometimes find some special libraries (something like libserial or libusb) that provide a nicer programming interface to the resp. devices.
Now, obviously, not every user should be allowed to read/write to a device, right? This is why you'd find that entries under /dev to be owned by user root and having rw permissions only for root.
What this means is that if you write an application to talk to one of the devices using one of these entries, your app needs to be run as root.
In some cases, the device may need to be available/usable by other non-root users but still maintain sanctity of the system. In such cases, you'd find that there is a daemon/service running that talks to the device and provides a well-defined and restricted API for the application.
HTH
Bookmarks