15. Individual Modules
In this chapter, I document individual LKMs. Where possible, I do this by reference to more authoritative documentation for the particular LKM (probably maintained by the same person who maintains the LKM code).
15.1. Executable Interpreters
15.2. Block Device Drivers
15.3. SCSI Drivers
15.4. Network Device Drivers
15.5. CDROM Device Drivers
15.6. Filesystem Drivers
15.7. Miscellaneous Device Driver
15.8. Serial Device Drivers
15.9. Parallel Device Drivers
15.10. Bus Mouse Device Drivers
15.11. Tape Device Drivers
15.12. Watchdog Timers
15.13. Sound Device Drivers
That one bound-in executable interpreter is almost certainly the ELF interpreter, since virtually all executables in a Linux system are ELF.
Historical note: Before ELF existed on Linux (c. 1995), the normal executable format was a.out. For a while, part ELF/part a.out systems were common. Some still exist.
If you try to run an a.out executable without this, your exec system call fails with a "cannot execute binary file" error.
There are no LKM parameters.
Example:
It's almost inconceivable that you wouldn't have this executable interpreter bound into the base kernel (if for no other reason that your insmod is probably an ELF executable). However, it is conceptually possible to leave it out of the base kernel and insert it as an LKM.
There are no LKM parameters.
Example:
While the intent was that the bytecode interpreter would run as a user space program, with this LKM you can make the Linux kernel interpret Java bytecode like any other executable format. So you can run a program compiled from Java the same as you would run a program compiled from C (e.g. type its name at a command shell prompt).
In practice, the advantages of the intermediate bytecode language have not been proven and it is quite common to compile Java directly to a more traditional executable format, such as ELF. If you do that, you don't need binfmt_java .
There are no LKM parameters.
Example:
In this chapter, I document individual LKMs. Where possible, I do this by reference to more authoritative documentation for the particular LKM (probably maintained by the same person who maintains the LKM code).
15.1. Executable Interpreters
15.2. Block Device Drivers
15.3. SCSI Drivers
15.4. Network Device Drivers
15.5. CDROM Device Drivers
15.6. Filesystem Drivers
15.7. Miscellaneous Device Driver
15.8. Serial Device Drivers
15.9. Parallel Device Drivers
15.10. Bus Mouse Device Drivers
15.11. Tape Device Drivers
15.12. Watchdog Timers
15.13. Sound Device Drivers
15.1. Executable Interpreters
You must have at least one executable interpreter bound into the base kernel, because in order to load an executable interpreter LKM, you have to run an executable and something has to interpret that executable.That one bound-in executable interpreter is almost certainly the ELF interpreter, since virtually all executables in a Linux system are ELF.
Historical note: Before ELF existed on Linux (c. 1995), the normal executable format was a.out. For a while, part ELF/part a.out systems were common. Some still exist.
15.1.1. binfmt_aout: executable interpreter for a.out format
a.out is the venerable executable format that was common in Unix's early history and originally Linux's only executable format. To this day, the default name of the executable output file of the GNU compiler is a.out (regardless of what it's format is).If you try to run an a.out executable without this, your exec system call fails with a "cannot execute binary file" error.
There are no LKM parameters.
Example:
modprobe binfmt_aout
15.1.2. binfmt_elf: executable interpreter for ELF format
ELF is the normal executable format on Linux systems.It's almost inconceivable that you wouldn't have this executable interpreter bound into the base kernel (if for no other reason that your insmod is probably an ELF executable). However, it is conceptually possible to leave it out of the base kernel and insert it as an LKM.
There are no LKM parameters.
Example:
modprobe binfmt_elf
15.1.3. binfmt_java: executable interpreter for Java bytecode
Java is a relatively modern object oriented programming language. Java programs are traditionally compiled into "Java bytecode" which is meant to be interpreted by a Java bytecode interpreter. The point of this new object language is that the bytecode object files are portable: Although different systems require different object formats, as long as each system has a bytecode interpreter, it can run bytecode object files. (This only works for a while, of course. If portability were that easy, all systems today would use the same object format anyway).While the intent was that the bytecode interpreter would run as a user space program, with this LKM you can make the Linux kernel interpret Java bytecode like any other executable format. So you can run a program compiled from Java the same as you would run a program compiled from C (e.g. type its name at a command shell prompt).
In practice, the advantages of the intermediate bytecode language have not been proven and it is quite common to compile Java directly to a more traditional executable format, such as ELF. If you do that, you don't need binfmt_java .
There are no LKM parameters.
Example:
modprobe binfmt_java
No comments:
Post a Comment