High Performance Computing most generally refers to the practice of aggregating computing power in a way that delivers much higher performance than one could get out of a typical desktop computer or workstation in order to solve large problems in science, engineering, or business.

pool of JSch ssh connections and I will use a simple getter setter object called ServerDetails as a key. Basically for each server I want to have a pool of 10 reusable ssh connections. So first thing to do is to create a Sessionfactory, a class in charge of creating the actual object you want to store in the pool. In our example that would be an ssh connection.

How does GRUB work?

When a computer boots, the BIOS transfers control to the first boot device, which can be a hard disk, a floppy disk, a CD-ROM, or any other BIOS-recognized device. We'll concentrate on hard disks, for the sake of simplicity.
The first sector on a hard is called the Master Boot Record (MBR). This sector is only 512 bytes long and contains a small piece of code (446 bytes) called the primary boot loader and the partition table (64 bytes) describing the primary and extended partitions.
By default, MBR code looks for the partition marked as active and once such a partition is found, it loads its boot sector into memory and passes control to it.
GRUB replaces the default MBR with its own code.
Furthermore, GRUB works in stages.
Stage 1 is located in the MBR and mainly points to Stage 2, since the MBR is too small to contain all of the needed data.
Stage 2 points to its configuration file, which contains all of the complex user interface and options we are normally familiar with when talking about GRUB. Stage 2 can be located anywhere on the disk. If Stage 2 cannot find its configuration table, GRUB will cease the boot sequence and present the user with a command line for manual configuration.
Stage 1.5 also exists and might be used if the boot information is small enough to fit in the area immediately after MBR.
The Stage architecture allows GRUB to be large (~20-30K) and therefore fairly complex and highly configurable, compared to most bootloaders, which are sparse and simple to fit within the limitations of the Partition Table.

How to extract a file from a rpm package - 3 easy ways

According to Peck Dickens:
1) The easiest way is to use Midnight Commander to navagate into the RPM and then copy the file out that you are interested in.
2) Another method is to do it at the command line using the following commands:
 cd /tmp
 md rpmtmp
 cd rpmtmp
 rpm2cpio {FullNameOfRPM} | cpio -iumd {FullNameOfFileToExtract}
Be sure to clean up after you.
According to Pam Roberts:
3) You can use rpm-get, which is in rpm-utils-1.5-1.noarch.rpm from your friendly local rpmfind.net and installs without any problems.

Writing device drivers in Linux: A brief tutorial

Pre-requisites

In order to develop Linux device drivers, it is necessary to have an understanding of the following:

• C programming. Some in-depth knowledge of C programming is needed, like pointer usage, bit manipulating functions, etc.
• Microprocessor programming. It is necessary to know how microcomputers work internally: memory addressing, interrupts, etc. All of these concepts should be familiar to an assembler programmer.

There are several different devices in Linux. For simplicity, this brief tutorial will only cover type char devices loaded as modules. Kernel 2.6.x will be used (in particular, kernel 2.6.8 under Debian Sarge, which is now Debian Stable).

User space and kernel space

When you write device drivers, it’s important to make the distinction between “user space” and “kernel space”.

• Kernel space. Linux (which is a kernel) manages the machine’s hardware in a simple and efficient manner, offering the user a simple and uniform programming interface. In the same way, the kernel, and in particular its device drivers, form a bridge or interface between the end-user/programmer and the hardware. Any subroutines or functions forming part of the kernel (modules and device drivers, for example) are considered to be part of kernel space.
• User space. End-user programs, like the UNIX shell or other GUI based applications (kpresenter for example), are part of the user space. Obviously, these applications need to interact with the system’s hardware . However, they don’t do so directly, but through the kernel supported functions.

Interfacing functions between user space and kernel space

The kernel offers several subroutines or functions in user space, which allow the end-user application programmer to interact with the hardware. Usually, in UNIX or Linux systems, this dialogue is performed through functions or subroutines in order to read and write files. The reason for this is that in Unix devices are seen, from the point of view of the user, as files.
On the other hand, in kernel space Linux also offers several functions or subroutines to perform the low level interactions directly with the hardware, and allow the transfer of information from kernel to user space.
Usually, for each function in user space (allowing the use of devices or files), there exists an equivalent in kernel space (allowing the transfer of information from the kernel to the user and vice-versa). This is shown in Table 1, which is, at this point, empty. It will be filled when the different device drivers concepts are introduced.

Events	User functions	Kernel functions
Load module
Open device
Read device
Write device
Close device
Remove module

Table 1. Device driver events and their associated interfacing functions in kernel space and user space.

Interfacing functions between kernel space and the hardware device

There are also functions in kernel space which control the device or exchange information between the kernel and the hardware. Table 2 illustrates these concepts. This table will also be filled as the concepts are introduced.

Events	Kernel functions
Read data
Write data

Table 2. Device driver events and their associated functions between kernel space and the hardware device.

The first driver: loading and removing the driver in user space

I’ll now show you how to develop your first Linux device driver, which will be introduced in the kernel as a module.
For this purpose I’ll write the following program in a file named nothing.c
<nothing.c> =

#include <linux/module.h>



MODULE_LICENSE("Dual BSD/GPL");

Since the release of kernel version 2.6.x, compiling modules has become slightly more complicated. First, you need to have a complete, compiled kernel source-code-tree. If you have a Debian Sarge system, you can follow the steps in Appendix B (towards the end of this article). In the following, I’ll assume that a kernel version 2.6.8 is being used.
Next, you need to generate a makefile. The makefile for this example, which should be named Makefile, will be:
<Makefile1> =

obj-m := nothing.o

Unlike with previous versions of the kernel, it’s now also necessary to compile the module using the same kernel that you’re going to load and use the module with. To compile it, you can type:
$ make -C /usr/src/kernel-source-2.6.8 M=pwd modules
This extremely simple module belongs to kernel space and will form part of it once it’s loaded.
In user space, you can load the module as root by typing the following into the command line:
# insmod nothing.ko
The insmod command allows the installation of the module in the kernel. However, this particular module isn’t of much use.
It is possible to check that the module has been installed correctly by looking at all installed modules:
# lsmod
Finally, the module can be removed from the kernel using the command:
# rmmod nothing
By issuing the lsmod command again, you can verify that the module is no longer in the kernel.
The summary of all this is shown in Table 3.

Events	User functions	Kernel functions
Load module	insmod
Open device
Read device
Write device
Close device
Remove module	rmmod

Table 3. Device driver events and their associated interfacing functions between kernel space and user space.

The “Hello world” driver: loading and removing the driver in kernel space

When a module device driver is loaded into the kernel, some preliminary tasks are usually performed like resetting the device, reserving RAM, reserving interrupts, and reserving input/output ports, etc.
These tasks are performed, in kernel space, by two functions which need to be present (and explicitly declared): module_init and module_exit; they correspond to the user space commands insmod and rmmod , which are used when installing or removing a module. To sum up, the user commands insmod and rmmod use the kernel space functions module_init and module_exit.
Let’s see a practical example with the classic program Hello world:
<hello.c> =

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>

MODULE_LICENSE("Dual BSD/GPL");

static int hello_init(void) {
  printk("<1> Hello world!\n");

  return 0;
}

static void hello_exit(void) {
  printk("<1> Bye, cruel world\n");
}

module_init(hello_init);
module_exit(hello_exit);

The actual functions hello_init and hello_exit can be given any name desired. However, in order for them to be identified as the corresponding loading and removing functions, they have to be passed as parameters to the functions module_init and module_exit.
The printk function has also been introduced. It is very similar to the well known printf apart from the fact that it only works inside the kernel. The <1> symbol shows the high priority of the message (low number). In this way, besides getting the message in the kernel system log files, you should also receive this message in the system console.
This module can be compiled using the same command as before, after adding its name into the Makefile.
<Makefile2> =

obj-m := nothing.o hello.o 

In the rest of the article, I have left the Makefiles as an exercise for the reader. A complete Makefile that will compile all of the modules of this tutorial is shown in Appendix A.
When the module is loaded or removed, the messages that were written in the printk statement will be displayed in the system console. If these messages do not appear in the console, you can view them by issuing the dmesg command or by looking at the system log file with cat /var/log/syslog.
Table 4 shows these two new functions.

Events	User functions	Kernel functions
Load module	insmod	module_init()
Open device
Read device
Write device
Close device
Remove module	rmmod	module_exit()

Table 4. Device driver events and their associated interfacing functions between kernel space and user space.

The complete driver “memory”: initial part of the driver

I’ll now show how to build a complete device driver: memory.c. This device will allow a character to be read from or written into it. This device, while normally not very useful, provides a very illustrative example since it is a complete driver; it’s also easy to implement, since it doesn’t interface to a real hardware device (besides the computer itself).

To develop this driver, several new #include statements which appear frequently in device drivers need to be added:
<memory initial> =

/* Necessary includes for device drivers */
#include <linux/init.h>
#include <linux/config.h>
#include <linux/module.h>
#include <linux/kernel.h> /* printk() */
#include <linux/slab.h> /* kmalloc() */

#include <linux/fs.h> /* everything... */
#include <linux/errno.h> /* error codes */
#include <linux/types.h> /* size_t */
#include <linux/proc_fs.h>
#include <linux/fcntl.h> /* O_ACCMODE */

#include <asm/system.h> /* cli(), *_flags */
#include <asm/uaccess.h> /* copy_from/to_user */

MODULE_LICENSE("Dual BSD/GPL");

/* Declaration of memory.c functions */
int memory_open(struct inode *inode, struct file *filp);

int memory_release(struct inode *inode, struct file *filp);
ssize_t memory_read(struct file *filp, char *buf, size_t count, loff_t *f_pos);
ssize_t memory_write(struct file *filp, char *buf, size_t count, loff_t *f_pos);

void memory_exit(void);
int memory_init(void);

/* Structure that declares the usual file */
/* access functions */
struct file_operations memory_fops = {
  read: memory_read,
  write: memory_write,

  open: memory_open,
  release: memory_release
};

/* Declaration of the init and exit functions */
module_init(memory_init);
module_exit(memory_exit);

/* Global variables of the driver */
/* Major number */

int memory_major = 60;
/* Buffer to store data */
char *memory_buffer;

After the #include files, the functions that will be defined later are declared. The common functions which are typically used to manipulate files are declared in the definition of the file_operations structure. These will also be explained in detail later. Next, the initialization and exit functions—used when loading and removing the module—are declared to the kernel. Finally, the global variables of the driver are declared: one of them is the major number of the driver, the other is a pointer to a region in memory, memory_buffer, which will be used as storage for the driver data.

The “memory” driver: connection of the device with its files

In UNIX and Linux, devices are accessed from user space in exactly the same way as files are accessed. These device files are normally subdirectories of the /dev directory.
To link normal files with a kernel module two numbers are used: major number and minor number. The major number is the one the kernel uses to link a file with its driver. The minor number is for internal use of the device and for simplicity it won’t be covered in this article.
To achieve this, a file (which will be used to access the device driver) must be created, by typing the following command as root:
# mknod /dev/memory c 60 0
In the above, c means that a char device is to be created, 60 is the major number and 0 is the minor number.
Within the driver, in order to link it with its corresponding /dev file in kernel space, the register_chrdev function is used. It is called with three arguments: major number, a string of characters showing the module name, and a file_operations structure which links the call with the file functions it defines. It is invoked, when installing the module, in this way:
<memory init module> =

int memory_init(void) {
  int result;

  /* Registering device */
  result = register_chrdev(memory_major, "memory", &memory_fops);
  if (result < 0) {
    printk(
      "<1>memory: cannot obtain major number %d\n", memory_major);

    return result;
  }

  /* Allocating memory for the buffer */
  memory_buffer = kmalloc(1, GFP_KERNEL); 
  if (!memory_buffer) { 
    result = -ENOMEM;
    goto fail; 
  } 
  memset(memory_buffer, 0, 1);


  printk("<1>Inserting memory module\n"); 
  return 0;

  fail: 
    memory_exit(); 
    return result;
}

Also, note the use of the kmalloc function. This function is used for memory allocation of the buffer in the device driver which resides in kernel space. Its use is very similar to the well known malloc function. Finally, if registering the major number or allocating the memory fails, the module acts accordingly.

The “memory” driver: removing the driver

In order to remove the module inside the memory_exit function, the function unregsiter_chrdev needs to be present. This will free the major number for the kernel.
<memory exit module> =
void memory_exit(void) { /* Freeing the major number */ unregister_chrdev(memory_

major, "memory"); /* Freeing buffer memory */ if (memory_buffer) { kfree(memory_buffer); } printk("<1>Removing memory module\n"); } The buffer memory is also freed in this function, in order to leave a clean kernel when removing the device driver.

The “memory” driver: opening the device as a file

The kernel space function, which corresponds to opening a file in user space (fopen), is the member open: of the file_operations structure in the call to register_chrdev. In this case, it is the memory_open function. It takes as arguments: an inode structure, which sends information to the kernel regarding the major number and minor number; and a file structure with information relative to the different operations that can be performed on a file. Neither of these functions will be covered in depth within this article.
When a file is opened, it’s normally necessary to initialize driver variables or reset the device. In this simple example, though, these operations are not performed.
The memory_open function can be seen below:
<memory open> =
int memory_open(struct inode *inode, struct file *filp) { /* Success */ return 0; } This new function is now shown in Table 5.

Events	User functions	Kernel functions
Load module	insmod	module_init()
Open device	fopen	file_operations: open
Read device
Write device
Close device
Remove module	rmmod	module_exit()

Table 5. Device driver events and their associated interfacing functions between kernel space and user space.

The “memory” driver: closing the device as a file

The corresponding function for closing a file in user space (fclose) is the release: member of the file_operations structure in the call to register_chrdev. In this particular case, it is the function memory_release, which has as arguments an inode structure and a file structure, just like before.
When a file is closed, it’s usually necessary to free the used memory and any variables related to the opening of the device. But, once again, due to the simplicity of this example, none of these operations are performed.
The memory_release function is shown below:
<memory release> =

int memory_release(struct inode *inode, struct file *filp) {
 
  /* Success */
  return 0;
}

This new function is shown in Table 6.

Events	User functions	Kernel functions
Load module	insmod	module_init()
Open device	fopen	file_operations: open
Read device
Write device
Close device	fclose	file_operations: release
Remove module	rmmod	module_exit()

Table 6. Device driver events and their associated interfacing functions between kernel space and user space.

The “memory” driver: reading the device

To read a device with the user function fread or similar, the member read: of the file_operations structure is used in the call to register_chrdev. This time, it is the function memory_read. Its arguments are: a type file structure; a buffer (buf), from which the user space function (fread) will read; a counter with the number of bytes to transfer (count), which has the same value as the usual counter in the user space function (fread); and finally, the position of where to start reading the file (f_pos).
In this simple case, the memory_read function transfers a single byte from the driver buffer (memory_buffer) to user space with the function copy_to_user:
<memory read> =
ssize_t memory_read(struct file *filp, char *buf, size_t count, loff_t *f_pos) { /* Transfering data to user space */ copy_to_user(buf,memory_buffer,1); /* Changing reading position as best suits */ if (*f_pos == 0) { *f_pos+=1; return 1; } else { return 0; } } The reading position in the file (f_pos) is also changed. If the position is at the beginning of the file, it is increased by one and the number of bytes that have been properly read is given as a return value, 1. If not at the beginning of the file, an end of file (0) is returned since the file only stores one byte.
In Table 7 this new function has been added.

Events	User functions	Kernel functions
Load module	insmod	module_init()
Open device	fopen	file_operations: open
Read device	fread	file_operations: read
Write device
Close device	fclose	file_operations: release
Remove modules	rmmod	module_exit()

Table 7. Device driver events and their associated interfacing functions between kernel space and user space.

The “memory” driver: writing to a device

To write to a device with the user function fwrite or similar, the member write: of the file_operations structure is used in the call to register_chrdev. It is the function memory_write, in this particular example, which has the following as arguments: a type file structure; buf, a buffer in which the user space function (fwrite) will write; count, a counter with the number of bytes to transfer, which has the same values as the usual counter in the user space function (fwrite); and finally, f_pos, the position of where to start writing in the file.
<memory write> =
ssize_t memory_write( struct file *filp, char *buf, size_t count, loff_t *f_pos) { char *tmp; tmp=buf+count-1; copy_from_user(memory_buffer,tmp,1); return 1; } In this case, the function copy_from_user transfers the data from user space to kernel space.
In Table 8 this new function is shown.

Events	User functions	Kernel functions
Load module	insmod	module_init()
Open device	fopen	file_operations: open
Close device	fread	file_operations: read
Write device	fwrite	file_operations: write
Close device	fclose	file_operations: release
Remove module	rmmod	module_exit()

Device driver events and their associated interfacing functions between kernel space and user space.

The complete “memory” driver

By joining all of the previously shown code, the complete driver is achieved:
<memory.c> =
<memory initial> <memory init module> <memory exit module> <memory open> <memory release> <memory read> <memory write> Before this module can be used, you will need to compile it in the same way as with previous modules. The module can then be loaded with:
# insmod memory.ko
It’s also convenient to unprotect the device:
# chmod 666 /dev/memory
If everything went well, you will have a device /dev/memory to which you can write a string of characters and it will store the last one of them. You can perform the operation like this:
$ echo -n abcdef >/dev/memory
To check the content of the device you can use a simple cat:
$ cat /dev/memory
The stored character will not change until it is overwritten or the module is removed.

The real “parlelport” driver: description of the parallel port

I’ll now proceed by modifying the driver that I just created to develop one that does a real task on a real device. I’ll use the simple and ubiquitous computer parallel port and the driver will be called parlelport.
The parallel port is effectively a device that allows the input and output of digital information. More specifically it has a female D-25 connector with twenty-five pins. Internally, from the point of view of the CPU, it uses three bytes of memory. In a PC, the base address (the one from the first byte of the device) is usually 0x378. In this basic example, I’ll use just the first byte, which consists entirely of digital outputs.
The connection of the above-mentioned byte with the external connector pins is shown in figure 2.

The “parlelport” driver: initializing the module

The previous memory_init function needs modification—changing the RAM memory allocation for the reservation of the memory address of the parallel port (0x378). To achieve this, use the function for checking the availability of a memory region (check_region), and the function to reserve the memory region for this device (request_region). Both have as arguments the base address of the memory region and its length. The request_region function also accepts a string which defines the module.
<parlelport modified init module> =

/* Registering port */
  port = check_region(0x378, 1);
  if (port) { 
    printk("<1>parlelport: cannot reserve 0x378\n"); 
    result = port; 
    goto fail;
  } 
  request_region(0x378, 1, "parlelport");

The “parlelport” driver: removing the module

It will be very similar to the memory module but substituting the freeing of memory with the removal of the reserved memory of the parallel port. This is done by the release_region function, which has the same arguments as check_region.
<parlelport modified exit module> =

/* Make port free! */ 
  if (!port) { 
    release_region(0x378,1);
  }

The “parlelport” driver: reading the device

In this case, a real device reading action needs to be added to allow the transfer of this information to user space. The inb function achieves this; its arguments are the address of the parallel port and it returns the content of the port.
<parlelport inport> =

/* Reading port */
parlelport_buffer = inb(0x378);

Table 9 (the equivalent of Table 2) shows this new function.

Events	Kernel functions
Read data	inb
Write data

Device driver events and their associated functions between kernel space and the hardware device.

The “parlelport” driver: writing to the device

Again, you have to add the “writing to the device” function to be able to transfer later this data to user space. The function outb accomplishes this; it takes as arguments the content to write in the port and its address.
<parlelport outport> =

/* Writing to the port */
outb(parlelport_buffer,0x378);

Table 10 summarizes this new function.

Events	Kernel functions
Read data	inb
Write data	outb

Device driver events and their associated functions between kernel space and the hardware device.

The complete “parlelport” driver

I’ll proceed by looking at the whole code of the parlelport module. You have to replace the word memory for the word parlelport throughout the code for the memory module. The final result is shown below:
<parlelport.c> =
<parlelport initial> <parlelport init module> <parlelport exit module> <parlelport open> <parlelport release> <parlelport read> <parlelport write>

Initial section

In the initial section of the driver a different major number is used (61). Also, the global variable memory_buffer is changed to port and two more #include lines are added: ioport.h and io.h.
<parlelport initial> =
/* Necessary includes for drivers */ #include <linux/init.h> #include <linux/config.h> #include <linux/module.h> #include <linux/kernel.h> /* printk() */ #include <linux/slab.h> /* kmalloc() */ #include <linux/fs.h> /* everything... */ #include <linux/errno.h> /* error codes */ #include <linux/types.h> /* size_t */ #include <linux/proc_fs.h> #include <linux/fcntl.h> /* O_ACCMODE */ #include <linux/ioport.h> #include <asm/system.h> /* cli(), *_flags */ #include <asm/uaccess.h> /* copy_from/to_user */ #include <asm/io.h> /* inb, outb */ MODULE_LICENSE("Dual BSD/GPL"); /* Function declaration of parlelport.c */ int parlelport_open(struct inode *inode, struct file *filp); int parlelport_release(struct inode *inode, struct file *filp); ssize_t parlelport_read(struct file *filp, char *buf, size_t count, loff_t *f_pos); ssize_t parlelport_write(struct file *filp, char *buf, size_t count, loff_t *f_pos); void parlelport_exit(void); int parlelport_init(void); /* Structure that declares the common */ /* file access fcuntions */ struct file_operations parlelport_fops = { read: parlelport_read, write: parlelport_write, open: parlelport_open, release: parlelport_release }; /* Driver global variables */ /* Major number */ int parlelport_major = 61; /* Control variable for memory */ /* reservation of the parallel port*/ int port; module_init(parlelport_init); module_exit(parlelport_exit);

Module init

In this module-initializing-routine I’ll introduce the memory reserve of the parallel port as was described before.
<parlelport init module> =

int parlelport_init(void) { 
  int result;

  /* Registering device */
  result = register_chrdev(parlelport_major, "parlelport", 
      &parlelport_fops);

  if (result < 0) { 
    printk(
      "<1>parlelport: cannot obtain major number %d\n",
      parlelport_major); 
    return result; 
  } 
   
  <parlelport modified init module>


  printk("<1>Inserting parlelport module\n"); 
  return 0;

  fail: 
    parlelport_exit(); 
    return result;
}

Removing the module

This routine will include the modifications previously mentioned.
<parlelport exit module> =
void parlelport_exit(void) { /* Make major number free! */ unregister_chrdev(parlelport_major, "parlelport"); <parlelport modified exit module> printk("<1>Removing parlelport module\n"); }

Opening the device as a file

This routine is identical to the memory driver.
<parlelport open> =
int parlelport_open(struct inode *inode, struct file *filp) { /* Success */ return 0; }

Closing the device as a file

Again, the match is perfect.
<parlelport release> =
int parlelport_release(struct inode *inode, struct file *filp) { /* Success */ return 0; }

Reading the device

The reading function is similar to the memory one with the corresponding modifications to read from the port of a device.
<parlelport read> =
ssize_t parlelport_read(struct file *filp, char *buf, size_t count, loff_t *f_pos) { /* Buffer to read the device */ char parlelport_buffer; <parlelport inport> /* We transfer data to user space */ copy_to_user(buf,&parlelport_buffer,1); /* We change the reading position as best suits */ if (*f_pos == 0) { *f_pos+=1; return 1; } else { return 0; } }

Writing to the device

It is analogous to the memory one except for writing to a device.
<parlelport write> =

ssize_t parlelport_write( struct file *filp, char *buf, 
  size_t count, loff_t *f_pos) {

  char *tmp;

  /* Buffer writing to the device */
  char parlelport_buffer;

  tmp=buf+count-1;

  copy_from_user(&parlelport_buffer,tmp,1);

  <parlelport outport>
  
  return 1; 

Final application: flashing lights

Finally, I’ll develop a pretty application which will make the LEDs flash in succession. To achieve this, a program in user space needs to be written with which only one bit at a time will be written to the /dev/parlelport device.
<lights.c> =
#include <stdio.h> #include <unistd.h></p> int main() { unsigned char byte,dummy; FILE * PARLELPORT; /* Opening the device parlelport */ PARLELPORT=fopen("/dev/parlelport","w"); /* We remove the buffer from the file i/o */ setvbuf(PARLELPORT,&dummy,_IONBF,1); /* Initializing the variable to one */ byte=1; /* We make an infinite loop */ while (1) { /* Writing to the parallel port */ /* to turn on a LED */ printf("Byte value is %d\n",byte); fwrite(&byte,1,1,PARLELPORT); sleep(1); /* Updating the byte value */ byte<<=1; if (byte == 0) byte = 1; } fclose(PARLELPORT); }

}

LEDs to test the use of the parallel port

In this section I’ll detail the construction of a piece of hardware that can be used to visualize the state of the parallel port with some simple LEDs.
WARNING: Connecting devices to the parallel port can harm your computer. Make sure that you are properly earthed and your computer is turned off when connecting the device. Any problems that arise due to undertaking these experiments is your sole responsibility.
The circuit to build is shown in figure 3 You can also read “PC & Electronics: Connecting Your PC to the Outside World” by Zoller as reference.
In order to use it, you must first ensure that all hardware is correctly connected. Next, switch off the PC and connect the device to the parallel port. The PC can then be turned on and all device drivers related to the parallel port should be removed (for example, lp, parport, parport_pc, etc.). The hotplug module of the Debian Sarge distribution is particularly annoying and should be removed. If the file /dev/parlelport does not exist, it must be created as root with the command:
# mknod /dev/parlelport c 61 0
Then it needs to be made readable and writable by anybody with:
# chmod 666 /dev/parlelport
The module can now be installed, parlelport. You can check that it is effectively reserving the input/output port addresses 0x378 with the command:
$ cat /proc/ioports
To turn on the LEDs and check that the system is working, execute the command:
$ echo -n A >/dev/parlelport
This should turn on LED zero and six, leaving all of the others off.
You can check the state of the parallel port issuing the command:
$ cat /dev/parlelport

Home » Issues » Issue 11

Writing device drivers in Linux: A brief tutorial

A quick and easy intro to writing device drivers for Linux like a true kernel developer!

Short URL: http://fsmsh.com/1238

• Xavier Calbet
• 2006-04-26
• Server side | Advanced
• 3 Up Down

Write a full post in response to this!

It can be compiled in the usual way:
$ gcc -o lights lights.c
and can be executed with the command:
$ lights
The lights will flash successively one after the other! The flashing LEDs and the Linux computer running this program are shown in figure 4.

Conclusion

Having followed this brief tutorial you should now be capable of writing your own complete device driver for simple hardware like a relay board (see Appendix C), or a minimal device driver for complex hardware. Learning to understand some of these simple concepts behind the Linux kernel allows you, in a quick and easy way, to get up to speed with respect to writing device drivers. And, this will bring you another step closer to becoming a true Linux kernel developer.

Appendix A. Complete Makefile

<Makefile> =

obj-m := nothing.o hello.o memory.o parlelport.o

Appendix B. Compiling the kernel on a Debian Sarge system

To compile a 2.6.x kernel on a Debian Sarge system you need to perform the following steps, which should be run as root:

1. Install the “kernel-image-2.6.x” package.
2. Reboot the machine to make this the running kernel image. This is done semi-automatically by Debian. You may need to tweak the lilo configuration file /etc/lilo.conf and then run lilo to achieve this.
3. Install the “kernel-source-2.6.x” package.
4. Change to the source code directory, cd /usr/src and unzip and untar the source code with bunzip2 kernel-source-2.6.x.tar.bz2 and tar xvf kernel-source-2.6.x.tar. Change to the kernel source directory with cd /usr/src/kernel-source-2.6.x
5. Copy the default Debian kernel configuration file to your local kernel source directory cp /boot/config-2.6.x .config.
6. Make the kernel and the modules with make and then make modules.

Appendix C. Exercises

If you would like to take on some bigger challenges, here are a couple of exercises you can do:

1. I once wrote two device drivers for two ISA Meilhaus boards, an analog to digital converter (ME26) and a relay control board (ME53). The software is available from the ADQ project. Get the newer PCI versions of these Meilhaus boards and update the software.
2. Take any device that doesn’t work on Linux, but has a very similar chipset to another device which does have a proven device driver for Linux. Try to modify the working device driver to make it work for the new device. If you achieve this, submit your code to the kernel and become a kernel developer yourself!

Comments and acknowledgements

Three years have elapsed since the first version of this document was written. It was originally written in Spanish and intended for version 2.2 of the kernel, but kernel 2.4 was already making its first steps at that time. The reason for this choice is that good documentation for writing device drivers, the Linux device drivers book (see bibliography), lagged the release of the kernel in some months. This new version is also coming out soon after the release of the new 2.6 kernel, but up to date documentation is now readily available in Linux Weekly News making it possible to have this document synchronized with the newest kernel.
Fortunately enough, PCs still come with a built-in parallel port, despite the actual trend of changing everything inside a PC to render it obsolete in no time. Let us hope that PCs still continue to have built-in parallel ports for some time in the future, or that at least, parallel port PCI cards are still being sold.
This tutorial has been originally typed using a text editor (i.e. emacs) in noweb format. This text is then processed with the noweb tool to create a LaTeX file ( .tex ) and the source code files ( .c ). All this can be done using the supplied makefile.document with the command make -f makefile.document.
I would like to thank the “Instituto Politécnico de Bragança”, the “Núcleo Estudantil de Linux del Instituto Politécnico de Bragança (NUX)”, the “Asociación de Software Libre de León (SLeón)” and the “Núcleo de Estudantes de Engenharia Informática da Universidade de Évora” for making this update possible.
The connection of the above-mentioned byte with the external connector pins is shown in figure 2.

Figure 2: The first byte of the parallel port and its pin connections with the external female D-25 connector

All of this is shown in figure 1.

Figure 1: User space where applications reside, and kernel space where modules or device drivers reside

HA Using Cluster Manager

Using Red Hat Cluster Manager with Lustre

From Lustre.org

Jump to: navigation, search

(Updated: Dec 2010)
DISCLAIMER - EXTERNAL CONTRIBUTOR CONTENT
This content was submitted by an external contributor. We provide this information as a resource for the Lustre™ open-source community, but we make no representation as to the accuracy, completeness or reliability of this information.

---

Contents [hide] 1 Preliminary Notes 2 Setting Up RedHat Cluster 2.1 Setting Up the openais Communication Stack 3 Installing RedHat Cluster 4 Installing the Lustrefs resource script 5 Configure your Cluster 5.1 Nodes 5.2 Fencing 5.3 Resource Manager 5.3.1 Resources 5.3.2 Failover Domains 5.3.3 Services 5.4 Start RedHat Cluster 5.4.1 cman service 5.4.2 rgmanager service 5.4.3 Verifying RedHat Cluster 5.5 Relocate services 6 Other tools to use with RedHat Cluster

This page describes how to configure and use Red Hat Cluster Manager with Lustre failover. Sven Trautmann has contributed this content.
For more about Lustre failover, see Configuring Lustre for Failover.

Preliminary Notes

This document is based on the RedHat Cluster version 2.0, which is part of RedHat Enterprise Linux version 5.5. For other versions or RHEL-based distributions, the syntax or methods to set up and run RedHat Cluster may differ.
In comparison with other HA solutions, RedHat Cluster as in RHEL 5.5 is an old HA solution. We recommend using other HA solutions like Pacemaker, if possible.
It is assumed that two Lustre server nodes share a number of Lustre targets. Each Lustre node provides a number of Lustre targets and, in case of a failure, the active/non-failed node takes over the Lustre targets of the failed nodes and makes them available to the Lustre clients.
Furthermore, to make sure the Lustre targets are mounted only on one of Lustre server nodes at a time, STONITH fencing is implemented. This requires a way to make sure the failed node is shut down in case of a failure. In the examples below, it is assumed that the Lustre server nodes are equipped with a service processor allowing to shut down a failed node using IPMI. For other methods of fencing, refer to the RedHat Cluster documentation.

Setting Up RedHat Cluster

Setting up RedHat Cluster consists of three steps:

• setup openais,
• configure the cluster and,
• start the RedHat cluster services

Setting Up the openais Communication Stack

The openais package is distributed with RHEL and can be installed using

rpm -i /path/to/RHEL-DVD/Server/openais0.80.6-16.el5.x86_64.rpm

or

yum install openais

if yum is configured to access the RHEL repository.
Once installed, the software looks for a configuration in the file /etc/ais/openais.conf .
Complete the following steps to set up the openais communication stack:
1. Edit the totem section of the openais.conf configuration file to designate the IP address and netmask of the interface(s) to be used. The totem section of the configuration file describes the way openais communicates between nodes.

totem {
 version: 2
 secauth: off
 threads: 0
 interface {
  ringnumber: 0
  bindnetaddr: 10.0.0.0
  mcastaddr: 226.94.1.1
  mcastport: 5405
 }
}

Openais uses the option bindnetaddr to determine which interface is to be used for cluster communication. In the example shown above, it is assumed that one of the node’s interfaces is configured on the network 10.0.0.0. The value of the option is calculated from the IP address AND the network mask for the interface (IP & MASK) so the final bits of the address are cleared. Thus the configuration file is independent of any node and can be copied to all nodes.
2. Create an AIS key

# /usr/sbin/ais-keygen
OpenAIS Authentication key generator.
Gathering 1024 bits for key from /dev/random.
Writing openais key to /etc/ais/authkey.

Installing RedHat Cluster

The minimum installation of RedHat Cluster consists of the Cluster Manager package cman and the Resource Group Manager package rgmanager. The cman package can be found in the RHEL repository. The rgmanager package is part of the Cluster repository. It can be found on the RHEL DVD/ISO image in the Cluster sub-directory and may need to be added to the yum configuration manually. With yum configured correctly RedHat Cluster can be installed using:

yum install cman rgmanager

If yum is not set up correctly, the rpm packages and their dependencies need to be installed manually.

Installing the Lustrefs resource script

The rgmanager package includes a number of resource scripts (/usr/share/cluster) which are used to integrate resources like network interfaces or file systems with rgmanager. Unfortunately, there is no resource script for Lustre included.
Luckily Giacomo Montagner posted an resource script on the lustre-discuss mailing list:
http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090623/7799de37/attachment-0001.bin
After downloading this file it needs to be copied to /usr/share/cluster/lustrefs.sh. Make sure the script is executable.

Configure your Cluster

RedHat Cluster uses /etc/cluster/cluster.conf as central configuration file. This file is in XML format. The complete schema of the XML file can be found at http://sources.redhat.com/cluster/doc/cluster_schema_rhel5.html.
The Basic structure of a cluster.conf file may look like this:

<?xml version="1.0" ?>
<cluster config_version="1" name="Lustre">
...
</cluster>

In this example the name of the cluster is set to Lustre and the version is initialized as 1. If the cluster configuration is updated the config_version attribute must be increased on all nodes in this cluster. RedHat cluster is usually used with more than two nodes providing resources. To tell RedHat cluster to work with two nodes the following cman attributes need to be set:

<cman expected_votes="1" two_node="1"/>

This tells cman, that there are only two nodes in a cluster and one vote is enough declare a node failed.

Nodes

Next the nodes which form the cluster need to be specified. Each cluster node need to be specified separately wrapped in an surrounding clusternodes tag.

<clusternodes>
    <clusternode name="lustre1" nodeid="1">
      <fence>
        <method name="single">
          <device lanplus="1" name="lustre1-sp"/>

        </method>
      </fence>
    </clusternode>
    <clusternode name="lustre2" nodeid="2">
      <fence>
        <method name="single">

          <device lanplus="1" name="lustre2-sp"/>
        </method>
      </fence>
    </clusternode>
  </clusternodes>

Each cluster node is given a name which must be it's hostname or IP address. Additionally a unique node ID needs to be specified. The fence tag assigned to each node specifies a fence device to use to shut down this cluster node. The fence devices are defined elsewhere in cluster.conf (see below for details).

Fencing

Fencing is essential to keep data on the Lustre file system consistent. Even with Multi-Mount-Protection enabled, fencing can make sure that a node in an unclear state is brought down for more analysis by the administrator.
To configure fencing, first some fence daemon options need to be specified. the fence_daemon tag is a direct child of the cluster tag.

<fence_daemon post_fail_delay="0" post_join_delay="3"/>
  <fence_daemon clean_start="0"/>

Depending on the hardware configuration, these values may differ for different installations. Please see the notes in the cluster_schema_rhel5 document (linked above) for details.
Each Lustre node in a cluster should be equipped with a fencing device. RedHat cluster supports a number of devices. More details on which devices are supported and how to configure them can be found in the cluster schema document. For this example IPMI based fencing devices are used. The fencedevices section may look like this:

<fencedevices>
    <fencedevice name="lustre1-sp" agent="fence_ipmilan" auth="password" ipaddr="10.0.1.1" login="root" passwd="supersecretpassword" option="off"/>

    <fencedevice name="lustre2-sp" agent="fence_ipmilan" auth="password" ipaddr="10.0.1.2" login="root" passwd="supersecretpassword" option="off"/>

  </fencedevices>

Every fence device has a number of attributes: name is used to define a name for this fencing device. This name is referred to in the fence part of the clusternode definition (see above). The agent defines the kind of fencing device to use. In this example an IPMI-over-Lan device is used. The remaining attributes are specific for the ipmilan device and are self-explanatory.

Resource Manager

The resource manager block of the cluster.conf is wrapped in a rm tag:

<rm>
    ..
  </rm>

It contains definitions of resources, failover domains, and services.

Resources

In the resources block of the cluster.conf file all Lustre targets of both clustered nodes are specified. In this example, four Lustre object storage targets are defined:

<resources>
      <lustrefs name="target1" mountpoint="/mnt/ost1" device="/path/to/ost1/device" force_fsck="0" force_unmount="0" self_fence="1"/>

      <lustrefs name="target2" mountpoint="/mnt/ost2" device="/path/to/ost2/device" force_fsck="0" force_unmount="0" self_fence="1"/>
      <lustrefs name="target3" mountpoint="/mnt/ost3" device="/path/to/ost3/device" force_fsck="0" force_unmount="0" self_fence="1"/>

      <lustrefs name="target4" mountpoint="/mnt/ost4" device="/path/to/ost4/device" force_fsck="0" force_unmount="0" self_fence="1"/>
    </resources>

To use the lustrefs resource definition it is essential that the lustrefs.sh script is installed in /usr/share/cluster as described above. To verify the script is installed correctly and has correct permission run

# /usr/share/cluster/lustrefs.sh --help
usage: /usr/share/cluster/lustrefs.sh {start|stop|status|monitor|restart|meta-data|verify-all}

Each lustrefs resource has a number of attributes. name defines how the resource can be addressed.

Failover Domains

Usually RedHat cluster is used to provide a service on a number of nodes, where one node takes over the service of a failed node. In this example a number of Lustre targets is provided by each of the Lustre server nodes. To allow such a configuration, the definition of two Failover domains is necessary. The definition of failoverdomains may look like this:

<failoverdomains>
     <failoverdomain name="first_first" ordered="1" restricted="1">
        <failoverdomainnode name="lustre1" priority="1"/>

        <failoverdomainnode name="lustre2" priority="2"/>
      </failoverdomain>
      <failoverdomain name="second_first" ordered="1" restricted="1">         

        <failoverdomainnode name="lustre1" priority="2"/>
        <failoverdomainnode name="lustre2" priority="1"/>
      </failoverdomain>
    </failoverdomains>

In this example, two fail-over-domains are created by adding the same nodes to each fail-over-domain, but the nodes are assigned different priorities.

Services

As a final configuration step the resources defined earlier are assigned to their fail-over-domain. This is done by defining a service for each of the Lustre nodes in the cluster and assign a domain. For the resources and fail-over-domains defined earlier this may look like this:

<service autostart="1" exclusive="0" recovery="relocate" domain="first_first" name="lustre_2">
      <lustrefs ref="target1"/>
      <lustrefs ref="target2"/>

    </service>

    <service autostart="1" exclusive="0" recovery="relocate" domain="second_first" name="lustre_1">
      <lustrefs ref="target3"/>

      <lustrefs ref="target4"/>
    </service>

In this example target1 and target2 are assigned to the first node and target3 and target4 are assigned to the second node by default.

Start RedHat Cluster

Before bringing up RedHat cluster, make sure cluster.conf is update/edited on both Lustre server nodes. Usually cluster.conf should be the same on both nodes. The only exception is, if the device paths differ on both nodes.

cman service

With cluster.conf in place of both nodes it's time to start the cman service. this is done by running

service cman start

on both clustered nodes. To verify cman is running clustat can be used:

bash-3.2# clustat 
Cluster Status for Lustre @ Tue Dec 14 11:27:36 2010
Member Status: Quorate

 Member Name                                      ID   Status
 ------ ----                                      ---- ------

 lustre1                                             1 Online, Local
 lustre2                                             2 Online

To enable the cman service permanently run:

chkconfig cman on

rgmanager service

With cman up and running it's time to start the resource group manager rgmanager by running

service rgmanager start

rgmanager will than start to bring up the Lustre targets assigned to each of the Lustre nodes.

Verifying RedHat Cluster

To verify the state of the cluster run clustat again. With the above configuration the output should look like this:

bash-3.2# clustat
Cluster Status for Lustre @ Tue Dec 14 13:12:07 2010
Member Status: Quorate

 Member Name                                    ID   Status
 ------ ----                                    ---- ------

 lustre1                                           1 Online, Local, rgmanager
 lustre2                                           2 Online, rgmanager

 Service Name                       Owner (Last)                       State         

 ------- ----                       ----- ------                       -----         
 service:lustre_1                   lustre1                            started       
 service:lustre_2                   lustre2                            started       

Relocate services

It may be necessary to relocate running lustre services manually. This can be done using clusvcadm as shown in the example below. First the service lustre_2 is assigned to node lustre2. After calling clusvcadm -r lustre_2 this service is relocated to node lustre1, as show in the last clustat output.

bash-3.2# clustat
Cluster Status for Lustre @ Tue Dec 14 15:00:00 2010
Member Status: Quorate

 Member Name                            ID   Status
 ------ ----                            ---- ------

 lustre1                                   1 Online, Local, rgmanager
 lustre2                                   2 Online, rgmanager

 Service Name                   Owner (Last)                  State         

 ------- ----                   ----- ------                  -----         
 service:lustre_1               lustre1                       started       
 service:lustre_2               lustre2                       started       

bash-3.2# clusvcadm -r lustre_2  
Trying to relocate service:lustre_2...Success
service:lustre_2 is now running on ldk-2-2-eth2
bash-3.2# clustat
Cluster Status for Lustre @ Tue Dec 14 15:01:00 2010
Member Status: Quorate


 Member Name                            ID   Status
 ------ ----                            ---- ------
 lustre1                                   1 Online, Local, rgmanager
 lustre2                                   2 Online, rgmanager


 Service Name                   Owner (Last)                  State         
 ------- ----                   ----- ------                  -----         
 service:lustre_1               lustre1                       started       

 service:lustre_2               lustre1                       started       

Other tools to use with RedHat Cluster

RedHat cluster is a complex system of programs and services. There are a number of tools available to interact and/or make working with RedHat Cluster easier. In this section a number of these tools are presented. For more details read the man pages.

cman_tool 

can be used to manage the cman subsystem. It can be used to add or remove nodes to a cluster configuration

ccs_tool 

may be used to update the configuration of the running cluster

clustat 

show the status of the cluster and if and where services are currently running

clusvcadm 

can be used to enable, disable or relocate services in a cluster

system-config-cluster 

a graphical user interface for cluster configuration