EmbLogic's Blog

The file_operations Structure

The file_operations structure is defined in linux/fs.h, and holds pointers to functions defined by the driver that perform various operations on the device. Each field of the structure corresponds to the address of some function defined by the driver to handle a requested operation.The file_operations structure is defined in linux/fs.h, and holds pointers to functions defined by the driver that perform various operations on the device. Each field of the structure corresponds to the address of some function defined by the driver to handle a requested operation.The file_operations structure holds the address of the module’s function that performs that operation

The file structure

Each device is represented in the kernel by a file structure, which is defined in linux/fs.h. Be aware that a file is a kernel level structure and never appears in a user space program. It’s not the same thing as a FILE, which is defined by glibc and would never appear in a kernel space function. Also, its name is a bit misleading; it represents an abstract open `file’, not a file on a disk, which is represented by a structure named inode

Registering A Device

The major number tells you which driver handles which device file. The minor number is used only by the driver itself to differentiate which device it’s operating on, just in case the driver handles more than one device.Adding a driver to your system means registering it with the kernel.

Unregistering A Device

We can’t allow the kernel module to be rmmod’ed whenever root feels like it. If the device file is opened by a process and then we remove the kernel module, using the file would cause a call to the memory location where the appropriate function (read/write) used to be.If we’re lucky, no other code was loaded there, and we’ll get an ugly error message. If we’re unlucky, another kernel module was loaded into the same location, which means a jump into the middle of another function within the kernel. The results of this would be impossible to predict, but they can’t be very positive.

chardev

The next code sample creates a char driver named chardev. You can cat its device file (or open the file with a program) and the driver will put the number of times the device file has been read from into the file

Writing Modules for Multiple Kernel Versions

The system calls, which are the major interface the kernel shows to the processes, generally stay the same across versions. A new system call may be added, but usually the old ones will behave exactly like they used to. This is necessary for backward compatibility — a new kernel version is not supposed to break regular processes. In most cases, the device files will also remain the same. On the other hand, the internal interfaces within the kernel can and do change between versions.

The Centronics parallel interface is an older and still widely-used standard I/O interface for connecting printer s and certain other devices to computers. The interface typically includes a somewhat cumbersome cable and a 36- pin male and female connector at the printer or other device. The cable plugs into a 25-pin parallel port on the computer. Data flows in one direction only, from the computer to the printer or other device. In addition to eight parallel data lines, other lines are used to read status information and send control signals. Centronics Corporation designed the original Centronics parallel interface for dot matrix printers. In 1981, IBM used this interface as an alternative to the slower one-bit-at-a-time serial interface.

When the Centronics parallel interface was first developed, the main peripheral was the printer. Since then, portable disk drives, tape backup drives, and CD-ROM players are among devices that have adopted the parallel interface. These new uses caused manufacturers to look at new ways to make the Centronics parallel interface better. In 1991, Lexmark, IBM, Texas instruments, and others met to discuss a standard that would offer more speed and bi-directional communication. Their effort and the sponsorship of the IEEE resulted in the IEEE 1284 committee. The IEEE 1284 standard was approved for release in March, 1994.

The IEEE 1284 standard specifies five modes of operation, each mode providing data transfer in either the forward direction (computer to peripheral), backward direction (peripheral to computer), or bi-directional (one direction at a time).

• Compatibility mode is the original Centronics parallel interface and intended for use with dot matrix printers and older laser printers. The compatibility mode can be combined with the nibble mode for bi-directional data transfer.
• Nibble mode allows data transfer back to the computer. The nibble mode uses the status lines to send 2 nibble s (4-bit units) of data to the computer in two data transfer cycles. This mode is best used with printers.
• Byte mode uses software driver s to disable the drivers that control the data lines in order for data to be sent from the printer to the computer. The data is sent at the same speed as when data is sent from the computer to the printer. One byte of data is transferred instead of the two data cycles required by the nibble mode.
• ECP mode (Enhanced Capability Port mode) is an advanced bi-directional mode for use with printers and scanner s. It allows data compression for image s, FIFO (first in, first out) for items in queue s, and high-speed, bi-directional communication. Data transfer occurs at two to four megabytes per second. An advanced feature of ECP is channel addressing . This is used for multifunction devices such as printer/fax/modem devices. For example, if a printer/fax/modem device needs to print and send data over the modem at the same time, the channel address software driver of the ECP mode assigns a new channel to the modem so that both devices can work simultaneously.
• EPP mode (Enhanced Parallel Port mode) was designed by Intel, Xircom, and Zenith Data Systems to provide a high-performance parallel interface that could also be used with the standard interface. EPP mode was adopted as part of the IEEE 1284 standard. The EPP mode uses data cycles that transfer data between the computer and the peripheral and address cycles that assign address, channel, or command information. This allows data transfer speeds of 500 kilobytes to 2 megabytes per second, depending on the speed of the slowest interface. The EPP mode is bi-directional. It is suited for network adapters, data acquisition, portable hard drives, and other devices that need speed.

The computer must determine what the capabilities of the attached peripheral are and which mode to utilize. The concept developed to determine these factors is called negotiation. Negotiation is a sequence of events on the parallel port interface that determines which IEEE 1284 modes the device can handle. An older device will not respond to the negotiation sequence and compatibility mode is selected to operate that device. A newer device will respond to the negotiation sequence and a more advanced mode can be set.

RCS file: init.c,v
Working file: init.c
head: 1.5
branch:
locks: strict
root: 1.5
access list:
symbolic names:
keyword substitution: kv
total revisions: 5;    selected revisions: 5
description:
this is the kernel file to find the major and minor numbers.
—————————-
revision 1.5    locked by: root;
date: 2014/02/13 12:11:07;  author: root;  state: Exp;  lines: +13 -12
extern the file_operations fops.
—————————-
revision 1.4
date: 2014/02/13 06:08:26;  author: root;  state: Exp;  lines: +28 -18
create no. of device by a one drivers using for loop and give the value 5 to the macro NODE.
—————————-
revision 1.3
date: 2014/02/12 16:08:36;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
—————————-
revision 1.2
date: 2014/02/11 07:28:57;  author: root;  state: Exp;  lines: +32 -24
allocate the memmory to the device ScullDev
—————————-
revision 1.1
date: 2014/02/11 04:24:33;  author: root;  state: Exp;
Initial revision
=============================================================================

Physical and virtual memory

Traditionally, one has physical memory, that is, memory that is actually present in the machine, and virtual memory, that is, address space. Usually the virtual memory is much larger than the physical memory, and some hardware or software mechanism makes sure that a program can transparently use this much larger virtual space while in fact only the physical memory is available. Nowadays things are reversed: on a Pentium II one can have 64 GB physical memory, while addresses have 32 bits, so that the virtual memory has a size of 4 GB. We’ll have to wait for a 64-bit architecture to get large amounts of virtual memory again. The present situation on a Pentium with more than 4 GB is that using the PAE (Physical Address Extension) it is possible to place the addressable 4 GB anywhere in the available memory, but it is impossible to have access to more than 4 GB at once.

Kinds of memory -> Kernel and user space work with virtual addresses (also called linear addresses) that are mapped to physical addresses by the memory management hardware. This mapping is defined by page tables, set up by the operating system. DMA devices use bus addresses. On an i386 PC, bus addresses are the same as physical addresses, but other architectures may have special address mapping hardware to convert bus addresses to physical addresses. Under Linux one has #include phys_addr = virt_to_phys(virt_addr); virt_addr = phys_to_virt(phys_addr); bus_addr = virt_to_bus(virt_addr); virt_addr = bus_to_virt(bus_addr); All this is about accessing ordinary memory. There is also “shared memory” on the PCI or ISA bus. It can be mapped inside a 32-bit address space using ioremap(), and then used via the readb(), writeb() (etc.) functions. Life is complicated by the fact that there are various caches around, so that different ways to access the same physical address need not give the same result. See asm/io.h and Documentation/{IO-mapping.txt,DMA-mapping.txt,DMA-API.txt}.

Kernel memory handling Pages –>The basic unit of memory is the page. Nobody knows how large a page is (that is why the Linux swapspace structure, with a signature at the end of a page, is so unfortunate), this is architecture-dependent, but typically PAGE_SIZE = 4096. (PAGE_SIZE equals 1 << PAGE_SHIFT, and PAGE_SHIFT is 12, 13, 14, 15, 16 on the various architectures). If one is lucky, the getpagesize() system call returns the page size. Usually, the page size is determined by the hardware: the relation between virtual addresses and physical addresses is given by page tables, and when a virtual address is referenced that does not (yet) correspond to a physical address, a page fault occurs, and the operating system can take appropriate action. Most hardware allows a very limited choice of page sizes. (For example, a Pentium II knows about 4KiB and 4MiB pages.) Kernel memory allocation Buddy system The kernel uses a buddy system with power-of-two sizes. For order 0, 1, 2, …, 9 it has lists of areas containing 2^order pages. If a small area is needed and only a larger area is available, the larger area is split into two halves (buddies), possibly repeatedly. In this way the waste is at most 50%. Since 2.5.40, the number of free areas of each order can be seen in /proc/buddyinfo. When an area is freed, it is checked whether its buddy is free as well, and if so they are merged. Read the code in mm/page_alloc.c. get_free_page The routine __get_free_page() will give us a page. The routine __get_free_pages() will give a number of consecutive pages. (A power of two, from 1 to 512 or so. The above buddy system is used.)

kmalloc

The routine kmalloc() is good for an area of unknown, arbitrary, smallish length, in the range 32-131072 (more precisely: 1/128 of a page up to 32 pages), preferably below 4096. For the sizes, see . Because of fragmentation, it will be difficult to get large consecutive areas from kmalloc(). These days kmalloc() returns memory from one of a series of slab caches (see below) with names like “size-32″, …, “size-131072″. Priority Each of the above routines has a flags parameter (a bit mask) indicating what behaviour is allowed. Deadlock is possible when, in order to free memory, some pages must be swapped out, or some I/O must be completed, and the driver needs memory for that. This parameter also indicated where we want the memory (below 16M for ISA DMA, or ordinary memory, or high memory). Finally, there is a bit specifying whether we would like a hot or a cold page (that is, a page likely to be in the CPU cache, or a page not likely to be there). If the page will be used by the CPU, a hot page will be faster. If the page will be used for device DMA the CPU cache would be invalidated anyway, and a cold page does not waste precious cache contents.

vmalloc

The routine vmalloc() has a similar purpose, but has a better chance of being able to return larger consecutive areas, and is more expensive. It uses page table manipulation to create an area of memory that is consecutive in virtual memory, but not necessarily in physical memory. Device I/O to such an area is a bad idea. It uses the above calls with GFP_KERNEL to get its memory, so cannot be used in interrupt context.

bigphysarea

There is a patch around, the ” BIGPHYSAREA PATCH”, allowing one to reserve a large area at boot time. Some devices need a lot of room (for video frame grabbing, scanned images, wavetable synthesis, etc.). See, e.g., video/zr36067.c.

The slab cache

The routine kmalloc is general purpose, and may waste up to 50% space. If certain size areas are needed very frequently, it makes sense to have separate pools for them. For example, Linux has separate pools for inodes, dentries, buffer heads. The pool is created using kmem_cache_create(), and allocation is by kmem_cache_alloc().

The number of special purpose caches is increasing quickly. I have here a 2.4.18 system with 63 slab caches, and a 2.5.56 one with 149 slab caches. Probably this number should be reduced a bit again.

Any application that runs on a Linux system is assigned a process ID or PID. This is a numerical representation of the instance of the application on the system. It is used by the system administrator who may have to debug or terminate processes by referencing the PID. Process Management is the series of tasks a System Administrator completes to monitor, manage, and maintain instances of running applications. Multitasking Process Management beings with an understanding concept of Multitasking. Linux is what is referred to as a preemptive multitasking operating system. Preemptive multitasking systems rely on a scheduler. The function of the scheduler is to control the process that is currently using the CPU. so there is parent process and child process. The process which creates another process is called parent process and latter is called child process. And each process has its own PID i.e. process identity number to distinguish the child from the parent. To get these process IDs, we use following functions a) getpid() // to get the current process id b) getppid() // to get the creator/ parent process id There are three methods of creating a process: a) Create a process with the use of loader from file system. b) Create a process from the code segment of the current program using system call c) Duplication of the program To create a process using this method (Duplicate) is done by using “fork()” fork function is a special function use to create a child process from a parent process. Using fork(), child process shares the code segment of its parent but both processes have different physical address. After completion of the child process, child process returns its control to parent and the parent process returns its control to the shell. child PID= parent PID + 1 PPID of child = PID of parent fork() function returns three values a) 0 (zero) : if the process is executed by child b) +ve value : means child is created and +ve value is child’s PID c) -ve value : ERROR…! i.e. child process is not created and we can use these values to know which process is executing.

doing structure pointer includeing arrays in loop with functions making linklist

1. Compatibility Mode
This mode defines the protocol used by most PCs to transfer data to a printer. It is commonly called the “Centronics” mode and is the method utilized with the standard parallel port. In this mode, data is placed on the port’s data lines, the printer status is checked for no errors and that it is not Busy, and then a data Strobe is generated by the software to clock the data to the printer.

Compatibility Mode phase transitions:
1. Write the data to the data register
2. Program reads the status register to check that the printer is not BUSY
3. If not BUSY, then Write to the Control Register to assert the STROBE line
4. Write to the Control register to de-assert the STROBE line

2. Nibble Mode
The Nibble mode is the most common way to get reverse channel data from a printer or peripheral. This mode is usually combined with the Compatibility mode or a proprietary forward channel mode to create a complete bi-directional channel.
All of the standard parallel ports provide 5 lines from the peripheral to the PC to be used for external status indications. Using these lines, a peripheral can send a byte of data (8-bits) by sending 2 nibbles (4-bits) of information to the PC in two data transfer cycles. Unfortunately, since the nACK line is generally used to provide a peripheral interrupt, the bits used to transfer a nibble are not conveniently packed into the byte defined by the Status register. For this reason, the software must read the status byte and then manipulate the bits in order to get a correct byte.

Nibble Mode phase transitions:
1. Host signals ability to take data by asserting HostBusy low
2. Peripheral responds by placing first nibble on status lines
3. Peripheral signals valid nibble by asserting PtrClk low
4. Host sets HostBusy high to indicate that it has received the nibble and is not yet ready for another nibble.
5. Peripheral sets PtrClk high to acknowledge host
6. States 1 through 5 repeat for the second nibble

3. Byte Mode
With later implementations of the parallel port interface, some manufacturers, led by IBM on the PS/2 parallel port, added the capability to disable the drivers used for driving the data lines, and allowed the data port to become an input read data port. This enables a peripheral to send an entire byte of data to the PC in one data transfer cycle by using the 8 data lines, rather than the two cycles required using the Nibble mode.
This ability enables a Byte mode for reverse channel data transfer that can be used to provide data rates into the PC approaching that of the Compatibility mode, from the PC. This type of port is sometimes referred to as a “enhanced bi-directional” port, and has caused some confusion when mistaken for an Enhanced Parallel Port (EPP).

Byte Mode signal transitions:
1. Host signals ability to take data by asserting HostBusy low
2. Peripheral responds by placing first byte on data lines
3. Peripheral signals valid byte by asserting PtrClk low
4. Host sets HostBusy high to indicate that it has received the and is not yet ready for another byte
5. Peripheral sets PtrClk high to acknowledge host. Host pulses HostClk as an acknowledgement to the peripheral
6. States 1 through 5 repeat for additional bytes

Completed my master array declaring functions of each type.

1. The IEEE 1284 standard allows for faster throughput and bidirectional data flow with a theoretical maximum throughput of 4 megabytes per second; actual throughput is around 2 megabytes/second, depending on hardware. In the printer venue, this allows for faster printing and back-channel status and management. Since the new standard allowed the peripheral to send large amounts of data back to the host, devices that had previously used SCSI interfaces could be produced at a much lower cost. This included scanners, tape drives, hard disks, computer networks connected directly via parallel interface, network adapters and other devices. No longer was the consumer required to purchase an expensive SCSI card—they could simply use their built-in parallel interface. These low-cost devices provided a platform to leapfrog the faster USB interface into its present popularity, displacing the parallel devices. However, the parallel interface remains highly popular in the printer industry, with displacement by USB only in consumer models.

IEEE 1284 can operate in five modes:

1.   Compatibility Mode, also known as Centronics standard or SPP, is a uni-directional implementation with only a few differences from the original Centronics design. This mode is almost exclusively used for printers. The only signals that the printer can send back to the host are some fixed-meaning status lines that signal common error conditions, such as the printer running out of paper.

2.  Nibble Mode is an interface that allows the device to transmit data four bits (a nibble) at a time, (re)using four of the status lines of Compatibility Mode for data. This is the Bi-tronics mode introduced by HP and is generally used for enhanced printer status. Although never officially supported with these, Nibble Mode works with most of the pre-IEEE-1284 Centronics interfaces as well.

3. Byte Mode, also known as “Bi-Directional” (although all modes except Compatibility Mode are in fact bi-directional), is a half-duplex mode that allows the device to transmit eight bits at a time using the same data lines that are used for the other direction. This mode is supported on a minority of pre-IEEE-1284 interfaces as well, such as those built into the IBM PS/2 computers; because of this, it is sometimes unofficially called the PS/2 mode.

4.   Enhanced Parallel Port (EPP) is a half-duplex bi-directional interface designed to allow devices like printers, scanners, or storage devices to transmit large amounts of data while quickly being able to switch channel direction. EPP can provide up to 2 MByte/s bandwidth, approximately 15 times the speed achieved with normal parallel-port communication with far less CPU overhead.[1]

5.Extended Capability Port (ECP) is a half-duplex bi-directional interface similar to EPP, except that PC implementations use direct memory access (usually ISA DMA on channel 3) to provide even faster data transfer than EPP by having the ISA DMA hardware and the parallel port interface hardware handle the work of transferring the data instead of letting the CPU do this work. Many devices that interface using this mode support RLE compression. ECP can provide up to 2.5 MByte/s of bandwidth, which is the natural limit of 8-bit ISA DMA.[2] An ECP interface on a PC can improve transfers to pre-IEEE-1284 printers as well, by reducing the CPU load during the transfer ; however, the transfer in that case is unidirectional.

Most recent computers that include a parallel port can operate the port in ECP or EPP mode, or both simultaneously.

IEEE-1284 requires that bi-directional device communication is always initiated in Nibble Mode. If the host receives no reply in this mode, it will assume that the device is a legacy printer, and enter Compatibility Mode. Oth

Driver Modules can take command line arguments, but not with the argc/argv you might be used to.

To allow arguments to be passed to your module, declare the variables that will take the values of the command line arguments as global and then use the module_param() macro, (defined in linux/moduleparam.h) to set the mechanism up. At runtime, insmod will fill the variables with any command line arguments that are given, like ./insmod mymodule.ko myvariable=5

RCS file: header.h,v
Working file: header.h
head: 1.1
branch:
locks: strict
raghav: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
including linux/moduleparam.h
—————————-
revision 1.1    locked by: raghav;
date: 2014/02/21 03:49:24;  author: raghav;  state: Exp;
Initial revision
=============================================================================

RCS file: entry.c,v
Working file: entry.c
head: 1.1
branch:
locks: strict
raghav: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
included module_param()
—————————-
revision 1.1    locked by: raghav;
date: 2014/02/21 03:52:45;  author: raghav;  state: Exp;
Initial revision
=============================================================================