These relate primary to the differences in the target's hardware and the software that serves as the interface. The primary way a userland program (that is, an application) interacts with the Linux kernel is through device nodes, which operate with the same set of rules as a file. Device nodes can be anywhere on a system. The practice is to put them in the /dev directory. Writing data into the device node passes that data into the waiting device driver running in the kernel, which can then react to the input. Reading from a device node results in the device driver supplying data; the exact sort of data depends on the device driver. Other device drivers supply an interface via system calls (also known as syscalls). Frequently, syscalls are supplied as well as a file interface. These are functions that register with the kernel to provide an interface that's a function call. When you make a system call, the parameters passed into the function are passed to the kernel, which then passes them along to the device driver that registered the syscall. After the device driver's call completes, any return data is passed back to you. Many device drivers that have a syscall type of interface supply an executable program that makes executing syscalls more convenient for you. A syscall interface and a device-node interface are both acceptable ways to provide access to system resources. What matters as an application developer is what's necessary to make those resources available on the development host. Many times, the development host can be populated with the same device drivers as the target machine. If that's not possible, you can construct the application code with a wrapper around the bits of code that read from and write to the device driver or make syscalls. This extra bit of code introduces additional overhead and code size, but the amount is inconsequential.
It's worth mentioning FIFOs, which are handy ways of emulating /dev/$(something) files that report the state of some hardware. As you recall from your data structures class, a FIFO is a First In First Out queue of data. In real life, it resembles a line at the bank: the order which the data is entered is the order in which it comes out the other side of the queue. In Linux, a FIFO is a special sort of internal data structure that has a file interface. Write to the FIFO, and it accumulates data so that when the reader asks for data, the queue is reduced. Create a FIFO by doing the following (you don't need root access to do this):
$ mkfifo ~/test-fifo
You open the file with a program called tail that prints out the contents of the file as soon as data becomes available. Call this terminal one:
$ tail -f ~/test-fifo
In another terminal window (terminal two), you can write to this file by doing the following:
$ echo something > $/test-fifo
On terminal one, "something" appears. You can pass as much data as desired; for example:
$ ls / > $/test-fifo
The FIFO has a limited amount of resources to store the data after it's been written but before it's read. The current limit is one page size, or about 4KB. The wonderful thought about FIFO is how it lets you read from it from the command line. This makes creating a simple fake device easy. A real-life example of this feature's usefulness is a board with a device driver for some digital IO buttons and a potentiometer. The buttons have a device driver that updates a file /dev/buttons with a new line of data when the button changes state. The device has six buttons, and the contents of /dev/buttons when none have been clicked is
0 0 0 0 0 0 <newline>
The corresponding 0 changes to a 1 while you hold down the button:
0 1 0 0 0 0 <newline>
It changes back to a 0 when you release the button. The code that reads from this device driver does so in a loop with scanf(). To test the code on a desktop machine, I created a FIFO /dev/buttons and ran a script that wrote into the FIFO to simulate the buttons being clicked:
echo "0 0 1 0 0 0" > /dev/buttons
That's all the code necessary to emulate the device on a desktop. This interface also makes it much easier to test the code before deployment. When you're thinking about how a device will interact with other parts of the system, put some thought into using what Linux already has in terms of interfaces, especially a file-type interface-doing so lets you leverage a host of other features.
Most programmers who explain programming languages and techniques start with a "Hello World" example. There's no need to break with tradition. You use the command prompt as the IDE; this is important because all IDE tools available for Linux create make files like the one you create here, based on the project's contents. Eventually, you must figure out how they work when a problem surfaces. Before getting started, you need the following:
The prior indications cover getting a cross-compiler for your system. If you've managed to build a crosscompiler from scratch, using crosstool-ng or a distribution builder tool, your system contains the necessary tools for this part of the article, because they were necessary to build the distribution. If you've paged ahead, or if you received a toolchain in binary form and you aren't interested in rebuilding the sources given to you with the binary (you got the source code, didn't you?), your system may not have the right set of tools. If you're not sure, run the following command anyway; the software informs you whether the most recent versions are installed and quits. If you're an Ubuntu user, use this command to fetch the host tools necessary for development:
$ sudo apt-get install build-essential gcc make
If you're running a system that uses RPM, do the following:
$ sudo yum install gcc make kernel-devel
In both cases, you're asked to confirm the installation. These commands fetch a version of GCC and make. As for the editor, there are no restrictions: you can even use OpenOffice Writer, as long as the files are saved as text. For a practical suggestion, use the text editor that's available on your system in the Accessories menu. Linux has no shortage of text editors.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Bradley G. Young at 02012010
1. Why is Linux such an incredible piece of sowtware
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.