EmbLogic » John McArthur

broadcom wireless (wifi) driver installation process

John McArthur — Sun, 07 Oct 2012 05:51:57 +0000

For Broadcom BCM4301 BCM4303 BCM4306 BCM4309
BCM4311 BCM4312 BCM4318

Install b43-fwcutter. This is the software package that does the extraction of the firmware from the proprietary driver.
Code:

[root]#su -
[root]yum install b43-fwcutter

Determine which native driver is being used by the wireless card (b43 or b43legacy). The kernel is generally good about detecting a Broadcom wireless card and loading the correct driver module for it. The following terminal command will list the loaded kernel modules in alphabetical order. Look for b43 or b43legacy.
Code:

[root]#lsmod | sort

Do this step only if you need to install version 4 firmware for the b43 driver module. Copy and execute the following command lines one after the other in a Fedora terminal.
Code:

[root]#wget http://downloads.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
[root]#tar xjf broadcom-wl-4.150.10.5.tar.bz2
[root]#cd broadcom-wl-4.150.10.5/driver
[root]su
[root]b43-fwcutter -w /lib/firmware wl_apsta_mimo.o

For Broadcom BCM4311 BCM4312 BCM4313 BCM4321
BCM4322 BCM43224 BCM43225 BCM43227 BCM43228
BCM4328 BCM43XG

1) Install the RPM Fusion repositories.
To enable access to both the free and the nonfree repository use the following command:

For Fedora 15, 16 and 17:

[root]#su -c ‘yum localinstall _nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm‘

2)Do this step only if you need to install the kmod version of the driver for the i686 or x86_64 kernels.
[root]#yum install kmod-wl

SELinux

John McArthur — Sat, 22 Sep 2012 10:09:44 +0000

If SELinux is enabled, the policy defines what access to resources and operations on them (e.g. read, write) are allowed (i.e. SELinux stops all access unless allowed by policy). This is why SELinux is called a ‘mandatory access control’ (MAC) system.
The policy design, implementation and testing against a defined security policy or requirements is important, otherwise there could be ‘a false sense of security’.
SELinux can confine an application within its own ‘domain’ and allow it to have the minimum privileges required to do its job. Should the application require access to networks or other applications (or their data), then (as part of the security policy design), this access would need to be granted (so at least it is known what interactions are allowed and what are not – a good security goal).
Should an application ‘do something’ it is not allowed by policy (intentional or otherwise), then SELinux would stop these actions.
Should an application ‘do something’ it is allowed by policy, then SELinux may contain any damage that maybe done intentional or otherwise. For example if an application is allowed to delete all of its data files or database entries, and the bug, virus or malicious user gains these privileges then it would be able to do the same, however the good news is that if the policy ‘confined’ the application and data, all your other data should still be there.
User login sessions can be confined to their own domains. This allows clients they run to be given only the privileges they need (e.g. admin users, sales staff users, HR staff users etc.). This again will confine/limit any damage or leakage of data.
Some applications (X-Windows for example) are difficult to confine as they are generally designed to have total access to all resources. SELinux can generally overcome these issues by providing sandboxing services.
SELinux will not stop memory leaks or buffer over-runs (because its not designed to do this), however it may contain the damage that maybe done.
SELinux will not stop all viruses/malware getting into the system (as there are many ways they could be introduced (including by legitimate users), however it should limit the damage or leaks they cause.
SELinux will not stop kernel vulnerabilities, however it may limit their effects.
It is very easy to add new rules to an SELinux policy using tools such as audit2allow(1) if a user has the relevant permissions, however be aware that this may start opening holes, so check what rules are really required.
Finally, SELinux cannot stop anything allowed by the security policy, so good design is important.

MODULE_DEVICE_TABLE Macro

John McArthur — Mon, 13 Aug 2012 10:49:45 +0000

This Macro is used by all USB and PCI drivers. This macro describes which devices each specific driver can support. At compilation time, the build process extracts this information out of the driver and builds a table. The table is called modules.pcimap and modules.usbmap for all PCI and USB devices, respectively, and exists in the directory /lib/modules/kernel_version/.

e.g.:-

static struct usb_device_id puzzle_id_table[]=
{
{ USB_DEVICE(VENDOR_ID,PRODUCT_ID) },
{0,},

};
MODULE_DEVICE_TABLE(usb,puzzle_id_table);

This will add following lines to modules.usbmap

# usb module match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info
lkm 0×0003 0×0951 0×1653 0×0000 0×0000 0×00 0×00 0×00 0×00 0×00 0×00 0×0

The macro MODULE_DEVICE_TABLE automatically creates two variables. For the example: MODULE_DEVICE_TABLE (usb, puzzle_id_table); the variables __module_usb_device_size and __module_usb_device_table are created and placed into the read-only data section and the initialized data section of the module, respectively. The variable __module_usb_device_size contains the value of the size of the struct usb_id structure, and __module_usb_device_table points to the puzzle_id_table structure. The puzzle_id_table variable is an array of usb_id structures with a terminating NULL structure at the end of the list.

When the depmod program is run, as part of the kernel installation process, it goes through every module looking for the symbol __module_usb_device_size to be present in the compiled module. If it finds it, it copies the data pointed to by the __module_usb_device_table symbol into a structure, extracts all of the information and writes it out to the modules.usbmap file, which is located in the module root directory.

Symbols From Another External Module (Module.symvers)

John McArthur — Sun, 12 Aug 2012 12:06:18 +0000

Sometimes, an external module uses exported symbols from
another external module. kbuild needs to have full knowledge of
all symbols to avoid spitting out warnings about undefined
symbols. Three solutions exist for this situation.
NOTE: The method with a top-level kbuild file is recommended
but may be impractical in certain situations.

Use a top-level kbuild file
If you have two modules, foo.ko and bar.ko, where
foo.ko needs symbols from bar.ko, you can use a
common top-level kbuild file so both modules are
compiled in the same build. Consider the following
directory layout:

./foo/ <= contains foo.ko
./bar/ <= contains bar.ko

The top-level kbuild file would then look like:

#./Kbuild (or ./Makefile):
obj-y := foo/ bar/

And executing

$ make -C $KDIR M=$PWD

will then do the expected and compile both modules with
full knowledge of symbols from either module.

Use an extra Module.symvers file
When an external module is built, a Module.symvers file
is generated containing all exported symbols which are
not defined in the kernel. To get access to symbols

from bar.ko, copy the Module.symvers file from the
compilation of bar.ko to the directory where foo.ko is
built. During the module build, kbuild will read the
Module.symvers file in the directory of the external
module, and when the build is finished, a new
Module.symvers file is created containing the sum of
all symbols defined and not part of the kernel.

Use “make” variable KBUILD_EXTRA_SYMBOLS
If it is impractical to copy Module.symvers from
another module, you can assign a space separated list
of files to KBUILD_EXTRA_SYMBOLS in your build file.
These files will be loaded by modpost during the
initialization of its symbol tables.

Install gnome desktop environment from terminal

John McArthur — Wed, 08 Aug 2012 04:50:47 +0000

At terminal you just have to type single line [root@localhost ~]# yum groupinstall “GNOME Desktop Environment” and then you’ll be provided with a lots of packages to download . Say yes to it. ANd BRAVO… you just turned on the … Continue reading →

Static an Dynamic power dissipation

John McArthur — Mon, 30 Jul 2012 06:25:51 +0000

The amount of power that a chip dissipates per unit area is called its power density, and there are two types of power density that concern processor architects: dynamic power density and static power density.

Dynamic Power Density

Each transistor on a chip dissipates a small amount of power when it is switched, and transistors that are switched rapidly dissipate more power than transistors that are switched slowly. The total amount of power dissipated per unit area due to switching of a chip’s transistors is called dynamic power density. There are two factors that work together to cause an increase in dynamic power density: clockspeed and transistor density.

Increasing a processor’s clockspeed involves switching its transistors more rapidly, and as I just mentioned, transistors that are switched more rapidly dissipate more power. Therefore, as a processor’s clockspeed rises, so does its dynamic power density, because each of those rapidly switching transistors contributes more to the device’s total power dissipation. You can also increase a chip’s dynamic power density by cramming more transistors into the same amount of surface area.
In addition to clockspeed-related increases in dynamic power density, chip designers must also contend with the fact that even transistors that aren’t switching will still leak current during idle periods, much like how a faucet that is shut off can still leak water if the water pressure behind it is high enough. This leakage current causes an idle transistor to constantly dissipate a trace amount of power. The amount of power dissipated per unit area due to leakage current is called static power density.

Install KDE Plasma Workspaces

John McArthur — Thu, 24 May 2012 09:26:45 +0000

To install KDE Plasma Workspaces using the command line, execute the following as root:

# yum install @kde-desktop

Recover deleted files in Linux

John McArthur — Tue, 15 May 2012 05:02:00 +0000

Scalpel

This is a filesystem-independent recovery tool for Linux and Mac OS, which you can also run on Windows by compiling it with MinGW. The latest version is 2.0. Install it in Fedora with

# yum install scalpel.

Next is some text editing — the configuration file is /etc/scalpel/scalpel.conf. You will find that everything has been commented out — uncomment the specific file format that you want to recover. For example, if I want to recover a deleted zip file, I will uncomment the .zip file section in scalpel.conf, as shown in Figure 1.

Figure 1: Scalpel.config file

Next, in a terminal, run:

# scalpel [device/directory/file name] -o [output directory]

The output directory, in which you want to store recovered files, should be empty before running Scalpel; otherwise, you will get an error.

Foremost

Foremost is a console program to recover files based on their headers, footers, and internal data structures. This process is commonly referred to as data carving. Foremost can work on disk or partition image files, such as those generated by dd, Safeback, Encase, etc, or directly on a drive.

The headers and footers can be specified by a configuration file, or you can use command-line switches to specify built-in file types. Install in Ubuntu and its derivatives with the following command:

# yum install foremost

There are a lot of options available. For example, to search for a deleted JPEG file, use:

# foremost -t jpg -i /dev/sda1

The -t (“type”) option can be given as -t all to search for all file types. Multiple file types are comma-separated, like -t jpg, pdf. The (required) option -i is the base device/directory for the search. You can also specify an output directory with -o.

Referrence :- http://www.linuxforu.com/2011/09/recover-deleted-files-in-linux/

MEMORY BARRIERS

John McArthur — Wed, 11 Apr 2012 06:57:57 +0000

Memory barriers are instructions to both the compiler and the CPU to 
impose a partial ordering between the memory access operations 
specified either side of the barrier.
Older and less complex CPUs will perform memory accesses in exactly 
the order specified, so if one is given the following piece of code:

	a = *A;
	*B = b;
	c = *C;
	d = *D;
	*E = e;

It can be guaranteed that it will complete the memory access for each
instruction before moving on to the next line, leading to a definite
sequence of operations on the bus:

	read *A, write *B, read *C, read *D, write *E.

However, with newer and more complex CPUs, this isn't always true 
because: 
 (*) they can rearrange the order of the memory accesses to promote 
     better use of the CPU buses and caches;

 (*) reads are synchronous and may need to be done immediately to 
     permit progress, whereas writes can often be deferred without
     a problem;

 (*) and they are able to combine reads and writes to improve 
     performance when talking to the SDRAM (modern SDRAM chips can 
     do batched accesses of adjacent locations, cutting down on
     transaction setup costs).

When a program runs on a single CPU, the hardware performs the necessary bookkeeping 
 to ensure that programs execute as if all memory operations were performed in the order 
specified by the programmer (program order), hence memory barriers are not necessary. 
However, when the memory is shared with multiple devices, such as other CPUs in a 
multiprocessor system, or memory mapped peripherals, out-of-order access may affect 
program behavior. For example, a second CPU may see memory changes made by the 
first CPU in a sequence which differs from program order.

So what you might actually get from the above piece of code is:

	read *A, read *C+*D, write *E, write *B

Under normal operation, this is probably not going to be a problem;
however,there are two circumstances where it definitely _can_ be a
problem:

 (1) I/O

    Many I/O devices can be memory mapped, and so appear to the CPU 
    as if they're just memory locations. However, to control the 
    device, the driver has to make the right accesses in exactly the
    right order.
    Consider, for example, an ethernet chipset such as the AMD 
    PCnet32. It presents to the CPU an "address register" and a bunch
    of "data registers".The way it's accessed is to write the index 
    of the internal register you want to access to the address 
    register, and then read or write the appropriate data register 
    to access the chip's internal register:

	*ADR = ctl_reg_3;
	reg = *DATA;

    The problem with a clever CPU or a clever compiler is that the 
    write to the address register isn't guaranteed to happen before
    the access to the data register, if the CPU or the compiler 
    thinks it is more efficient to defer the address write:

	read *DATA, write *ADR

    then things will break.
    The way to deal with this is to insert an I/O memory barrier 
    between the two accesses:

	*ADR = ctl_reg_3;
	mb();
	reg = *DATA;

    In this case, the barrier makes a guarantee that all memory accesses before the
  barrier will happen before all the memory accesses after the barrier. It does not
    guarantee that all memory accesses before the barrier will be 
    complete by the time the barrier is complete.

 (2) Multiprocessor interaction

    When there's a system with more than one processor, these may be
    working on the same set of data, but attempting not to use locks
    as locks are quite expensive. This means that accesses that 
    affect both CPUs may have to be carefully ordered to prevent 
    error.

    Consider the R/W semaphore slow path. In that, a waiting process
    is queued on the semaphore, as noted by it having a record on 
    its stack linked to the semaphore's list:

	struct rw_semaphore {
		...
		struct list_head waiters;
	};

	struct rwsem_waiter {
		struct list_head list;
		struct task_struct *task;
	};

   To wake up the waiter, the up_read() or up_write() functions 
   have to read the pointer from this record to know as to where 
   the next waiter record is, clear the task pointer, call 
   wake_up_process() on the task, and release the task struct 
   reference held:
	READ waiter->list.next;
	READ waiter->task;
	WRITE waiter->task;
	CALL wakeup
	RELEASE task

  If any of these steps occur out of order, then the whole thing 
  may fail.
  Note that the waiter does not get the semaphore lock again - it 
  just waits for its task pointer to be cleared. Since the record 
  is on its stack, this means that if the task pointer is cleared 
  before the next pointer in the list is read, then another CPU 
  might start processing the waiter and it might clobber its stack
  before up*() functions have a chance to read the next pointer.

    CPU 0				  CPU 1
  =========================	      ===========================
					down_xxx()
					Queue waiter
					Sleep
    up_yyy()
    READ waiter->task;
    WRITE waiter->task;
    
					Resume processing
					down_xxx() returns
					call foo()
					foo() clobbers *waiter
    
    READ waiter->list.next;
     --- OOPS ---

  This could be dealt with using a spinlock, but then the down_xxx()
  function has to get the spinlock again after it's been woken up, 
  which is a waste of resources. The way to deal with this is to 
  insert an SMP memory barrier: 
	READ waiter->list.next;
	READ waiter->task;
	smp_mb();
	WRITE waiter->task;
	CALL wakeup
	RELEASE task 

 In this case, the barrier makes a guarantee that all memory 
 accesses before the barrier will happen before all the memory 
 accesses after the barrier. It does not guarantee that all 
 memory accesses before the barrier will be complete by the time 
 the barrier is complete.
                         SMP memory barriers are normally no-ops on
 a UP system because the CPU orders overlapping accesses with 
respect to itself.
 
Referrece:-http://lwn.net/Articles/174655/

Optimization in GCC

John McArthur — Mon, 09 Apr 2012 10:01:46 +0000

Levels of Optimization

Let’s first look at how GCC categorizes optimizations and how a developer can control which are used and, sometimes more important, which are not. A large variety of optimizations are provided by GCC. Most are categorized into one of three levels, but some are provided at multiple levels. Some optimizations reduce the size of the resulting machine code, while others try to create code that is faster, potentially increasing its size. For completeness, the default optimization level is zero, which provides no optimization at all. This can be explicitly specified with option -O or -O0.
Level 1 (-O1)

The purpose of the first level of optimization is to produce an optimized image in a short amount of time. These optimizations typically don’t require significant amounts of compile time to complete. Level 1 also has two sometimes conflicting goals. These goals are to reduce the size of the compiled code while increasing its performance. The set of optimizations provided in -O1 support these goals, in most cases. These are shown in Table 1 in the column labeled -O1. The first level of optimization is enabled as:

gcc -O1 -o test test.c

Any optimization can be enabled outside of any level simply by specifying its name with the -f prefix, as:

gcc -fdefer-pop -o test test.c

We also could enable level 1 optimization and then disable any particular optimization using the -fno- prefix, like this:

gcc -O1 -fno-defer-pop -o test test.c

This command would enable the first level of optimization and then specifically disable the defer-pop optimization.
Level 2 (-O2)

The second level of optimization performs all other supported optimizations within the given architecture that do not involve a space-speed trade-off, a balance between the two objectives. For example, loop unrolling and function inlining, which have the effect of increasing code size while also potentially making the code faster, are not performed. The second level is enabled as:

gcc -O2 -o test test.c

The level -O2 optimizations include all of the -O1 optimizations, plus a large number of others.
Level 2.5 (-Os)

The special optimization level (-Os or size) enables all -O2 optimizations that do not increase code size; it puts the emphasis on size over speed. This includes all second-level optimizations, except for the alignment optimizations. The alignment optimizations skip space to align functions, loops, jumps and labels to an address that is a multiple of a power of two, in an architecture-dependent manner. Skipping to these boundaries can increase performance as well as the size of the resulting code and data spaces; therefore, these particular optimizations are disabled. The size optimization level is enabled as:

gcc -Os -o test test.c

In gcc 3.2.2, reorder-blocks is enabled at -Os, but in gcc 3.3.2 reorder-blocks is disabled.
Level 3 (-O3)

The third and highest level enables even more optimizations by putting emphasis on speed over size. This includes optimizations enabled at -O2 and rename-register. The optimization inline-functions also is enabled here, which can increase performance but also can drastically increase the size of the object, depending upon the functions that are inlined. The third level is enabled as:

gcc -O3 -o test test.c

Although -O3 can produce fast code, the increase in the size of the image can have adverse effects on its speed. For example, if the size of the image exceeds the size of the available instruction cache, severe performance penalties can be observed. Therefore, it may be better simply to compile at -O2 to increase the chances that the image fits in the instruction cache.

Referrence:- http://www.linuxjournal.com/article/7269

Anatomy of a Device Driver

John McArthur — Tue, 13 Mar 2012 13:16:23 +0000

A device driver has three sides: one side talks to the rest of the kernel, one talks to the hardware, and one talks to the user.

In order to talk to the kernel, the driver registers with subsystems to respond to events. Such an event might be the opening of a file, a page fault, the plugging in of a new USB device, etc.

User Interface of a Device driver
Since Linux follows the UNIX model, and in UNIX everything is a file, users talk with device drivers through device files. Device files are a mechanism, supplied by the kernel,
precisely for this direct User-Driver interface.

Anatomy of scull device driver
The user talks with scull through the /dev/scull device file.When the user opens /dev/scull, the kernel calls scull’s open routine. When the user closes /dev/scull, the kernel calls scull’s release routine
Scull talks to the kernel through its initialization function . . . and through register_chrdev
. . . and through hooking into the timer interrupt .

Driver Initialization Code
static int __init scull_module _init ( void )
{
int ret ;
pr_debug ( ” Scull module init called \ n ” ) ;
i f ( ( ret = register_chrdev (SCULL_MAJOR_NUM, ” scull ” , & scull _ fops printk(KERN_ERR ” register_chrdev : %d \ n ” , ret ) ;
return ret ;
}

Driver Initialization
One function (init) is called on the driver’s initialization.
One function (exit) is called when the driver is removed from the system.

Question: what happens if the driver is compiled into the kernel, rather than as a module?

The init function will register hooks that will get the driver’s code called when the appropriate event happens.
Question: what if the init function doesn’t register any hooks?
There are various hooks that can be registered: file
operations, pci operations, USB operations, network operations – it all depends on what kind of device this is.

Registering Chardev Hooks
struct file_operation scull_fops = {
. owner = THIS_MODULE,
. open = scull_open ,
. release = scull _ release ,
. read = scull _read ,
. wr i t e = scull _write ,
.mmap = scull_mmap ,
. ioctl = scull _ ioctl
} ;
. . .
i f ( ( ret = register_chrdev (SCULL_MAJOR_NUM, ” scull ” , & scull _fops ) ) < 0 )
printk (KERN_ERR ” register_chrdev : %d \ n ” , ret ) ;

User Space Access to the Driver
The driver registers a character device tied to a given major number, but how does the user create such a file?
# mknod /dev/scull c 250 0

And how does the user open it?
if ((kfd = open(“/dev/scull”, O_RDWR)) < 0) {
perror(“open /dev/scull”);
exit(EXIT_FAILURE);
}

File Operations
. . . and then you start talking to the device. scull uses the following device file operations:
open for allocating resources.
release for finishing releasing resources.
write for seting the starting positions
read for generating and then reading the next state .
mmap for potentially faster but more complex direct access .

The open and release Routines
open and release are where you perform any setup not done in initialization time and any cleanup not done in module unload time.

Scull_open
scull’s open routine allocates the scull structure which holds all of the state

static int scull_open ( struct inode *inode , struct file *filp )
{
struct scull *k ;
int ret ;
ret = alloc_scull (&k ) ;
if ( ret )
return ret ;
filp->private_data = k ;
return 0 ;
}

scull_release
scull’s release routine frees the resource allocated during open time.
static int scull_release ( struct inode *inode , struct file *filp )
{
struct scull *k = filp->pr i vate_data ;
…..
…..

free_scull ( k ) ;
return 0 ;
}

Open and Release
Beware of races if you have any global data . . . many a driver author stumble on this point.
Note also that release can fail, but almost no onechecks errors from close(), so it’s better if it doesn’t . . .
Question: what happens if the userspace program crashes while holding your device file open?

Use copy_from_user in case the user is passing a bad pointer.

Commentary on write
Note that even for such a simple function, care must be exercised when dealing with untrusted users.Users are always untrusted.
Always be prepared to handle errors!

memory mapping
The read-write mechanism, involves an overhead of a system call and related context switching and of memory copying. mmap maps pages of a file into memory, thus enabling
programs to directly access the memory directly and save the overhead, . . . but:
fast synchronization between kernel space and user space is a pain (why do we need it?),
and Linux read and write are really quite fast.

Referrence:-

Muli Ben-Yehuda IBM Haifa Research Labs and Haifux – Haifa Linux Club
Understanding the Linux Kernel, by Bovet and Cesati
Linux Device Drivers, 3rd edition, by Rubini et. al.
Linux Kernel Development, 2nd edition, by Robert Love
/usr/src/linux-xxx/

Block driver : Disk On RAM

John McArthur — Tue, 28 Feb 2012 15:44:39 +0000

-> Load the driver using insmod. This would create the block device files representing the disk on 512 KiB of RAM, with three primary and three logical partitions.
–> Check out the automatically created block device files (/dev/sd*). /dev/sdb is the entire disk, which is 512 KiB in size. sdb1, sdb2 and sdb3 are the primary partitions.
–> Read the entire disk (/dev/sdb) using the disk dump utility dd.
–> Zero out the first sector of the disk’s first partition (/dev/sdb1), again using dd.
–> Write some text into the disk’s first partition (/dev/sdb1) using cat.
–> Display the initial contents of the first partition (/dev/sdb1) using the xxd utility.
–> Display the partition information for the disk using fdisk.
–> Quick-format the third primary partition (/dev/sdb3) as a vfat filesystem (like your pen drive), using mkfs.vfat
–> Mount the newly formatted partition using mount, say at /mnt
–> The disk usage utility df would now show this partition mounted at /mnt . You may go ahead and store files there, but remember that this is a disk on RAM, and so is non-persistent.
Unload the driver using rmmod dor after unmounting the partition using umount /mnt. All data on the disk will be lost.

The block driver basics

Conceptually, the block drivers are very similar to character drivers, especially with regards to the following:

Usage of device files
Major and minor numbers
Device file operations
Concept of device registration

So, if you already know character driver implementation, it would be easy to understand block drivers.

However, they are definitely not identical. The key differences are as follows:

Abstraction for block-oriented versus byte-oriented devices.
Block drivers are designed to be used by I/O schedulers, for optimal performance. Compare that with character drivers that are to be used by VFS.
Block drivers are designed to be integrated with the Linux buffer cache mechanism for efficient data access. Character drivers are pass-through drivers, accessing the hardware directly.

And these cause the implementation differences. Let’s analyse the code .
The first step is to register for an 8-bit (block) major number (which implicitly means registering for all 256 8-bit minor numbers associated with it). The function for that is as follows:
int register_blkdev(unsigned int major, const char *name);

Here, major is the major number to be registered, and name is a registration label displayed under the kernel window /proc/devices. Interestingly, register_blkdev() tries to allocate and register a freely available major number, when 0 is passed for its first parameter major; on success, the allocated major number is returned. The corresponding de-registration function is as follows:
void unregister_blkdev(unsigned int major, const char *name);

Both these are prototyped in .

The second step is to provide the device file operations, through the struct block_device_operations (prototyped in ) for the registered major number device files.

However, these operations are too few compared to the character device file operations, and mostly insignificant. To elaborate, there are no operations even to read and write, which is surprising. But as we already know that block drivers need to integrate with the I/O schedulers, the read-write implementation is achieved through something called request queues. So, along with providing the device file operations, the following need to be provided:

The request queue for queuing the read/write requests
The spin lock associated with the request queue to protect its concurrent access
The request function to process the requests in the request queue

Also, there is no separate interface for block device file creations, so the following are also provided:

The device file name prefix, commonly referred to as disk_name (sdb in the my driver)
The starting minor number for the device files, commonly referred to as first_minor.

Finally, two block-device-specific things are also provided, namely:

The maximum number of partitions supported for this block device, by specifying the total minors.
The underlying device size in units of 512-byte sectors, for the logical block access abstraction.

All these are registered through the struct gendisk using the following function:
void add_disk(struct gendisk *disk);

The corresponding delete function is as follows:
void del_gendisk(struct gendisk *disk);

Prior to add_disk(), the various fields of struct gendisk need to initialised, either directly or using various macros/functions like set_capacity(). major, first_minor, fops, queue, disk_name are the minimal fields to be initialised directly. And even before the initialisation of these fields, the struct gendisk needs to be allocated, using the function given below:
struct gendisk *alloc_disk(int minors);

Here, minors is the total number of partitions supported for this disk. And the corresponding inverse function would be:
void put_disk(struct gendisk *disk);

All these are prototyped in .

Request queue and the request function

The request queue also needs to be initialised and set up into the struct gendisk, before add_disk(). The request queue is initialised by calling:
struct request_queue *blk_init_queue(request_fn_proc *, spinlock_t *);

We provide the request-processing function and the initialised concurrency protection spin-lock as parameters. The corresponding queue clean-up function is given below:
void blk_cleanup_queue(struct request_queue *);

The request (processing) function should be defined with the following prototype:
void request_fn(struct request_queue *q);

It should be coded to fetch a request from its parameter q, for instance, by using the following:
struct request *blk_fetch_request(struct request_queue *q);

Then it should either process it, or initiate processing. Whatever it does should be non-blocking, as this request function is called from a non-process context, and also after taking the queue’s spin-lock. Moreover, only functions not releasing or taking the queue’s spin-lock should be used within the request function.

A typical example of request processing, is given below:
while ((req = blk_fetch_request(q)) != NULL) /* Fetching a request */
{
/* Processing the request: the actual data transfer */
ret = rb_transfer(req); /* Our custom function */
/* Informing that the request has been processed with return of ret */
__blk_end_request_all(req, ret);
}

The gendisk interface in Block driver

John McArthur — Tue, 28 Feb 2012 05:12:49 +0000

In 2.6 kernel the gendisk is at the core of the block subsystem; if you need to work with or find something out about a disk, struct gendisk probably has what you need.
The best way of looking at the contents of a gendisk structure from a block driver’s point of view is to examine what that driver must do to set the structure up in the first place. If your driver makes a disk (or disk-like) device available to the system, it will have to provide an associated gendisk structure. The first step is to create the gendisk structure itself; the function you need is alloc_disk() .
struct gendisk *alloc_disk(int minors);
The argument minors is the maximum number of minor numbers that this disk can have. Minor numbers correspond to partitions.If a single minor number is requested, the device cannot be partitioned at all.
There are several fields of the gendisk structure which must be initialized by the block driver. They include:

int major;
The major number of this device; either a static major assigned to a specific driver, or one that was obtained dynamically from register_blkdev()

int first_minor;
The first minor device number corresponding to this disk. This number will be determined by how your driver divides up its minor number space.

char disk_name[32];
The name of this disk (i.e. hda). This name is used in places like /proc/partitions and in creating a sysfs directory for the device.

struct block_device_operations *fops;
The device operations (open, release, ioctl, media_changed, and revalidate_disk) for this device. Each disk has its own set of operations in 2.6.

struct request_queue *queue;
The request queue which will handle the list of pending operations for this disk. The queue must be created and initialized separately.

int flags;
A set of flags controlling the management of this device. They include GENHD_FL_REMOVABLE for removable devices, GENHD_FL_CD for CDROM devices, and GENHD_FL_DRIVERFS which certainly means something interesting, but which is not actually used anywhere.

void *private_data;
This field is reserved for the driver; the rest of the block subsystem will not touch it. Usually it holds a pointer to a driver-specific data structure describing this device.

The gendisk structure also holds the size of the disk, in sectors. As part of the initialization process, the driver should set that size with:

void set_capacity(struct gendisk *disk, sector_t size);

The size value should be in 512-byte sectors, even if the hardware sector size used by your device is different. For removable disks, setting its capacity to zero indicates to the block subsystem that there is currently no media present in the device. Once you have your gendisk structure set up, you have to add it to the list of active disks; that is done with:

void add_disk(struct gendisk *disk);

After this call, your device is live.

There are a few things worth keeping in mind about add_disk():

–>add_disk() can create I/O to the device (to read partition tables and such). You should not call add_disk() until your driver is sufficiently initialized to handle requests.

–> If you are calling add_disk() in your driver initialization routine, you should not fail the initialization process after the first call.

–> The call to add_disk() increments the disk’s reference count; if the disk structure is ever to be released, the driver is responsible for decrementing that count (with put_disk()).

To remove a disk from the system, that is accomplished with:

void del_gendisk(struct gendisk *disk);

This function cleans up all of the information associated with the given disk, and generally removes it from the system. After a call to del_gendisk(), no more operations will be sent to the given device. Your driver’s reference to the gendisk object remains, though; you must explicitly release it with:

void put_disk(struct gendisk *disk);
That call will cause the gendisk structure to be freed, as long as no other part of the kernel retains a reference to it.

Note–>sbd_request() uses the blk_fetch_request(), blk_rq_pos(), blk_rq_cur_sectors() and __blk_end_request_cur() functions rather than elv_next_request(), req->sector, req->current_nr_sectors and end_request() respectively. The structure of the loop also changes so we handle each sector from the request individually.

cvs server:cannot open /root/.cvsignore: Permission denied OR cvs [server aborted]: can’t chdir(/root):Permission denied

John McArthur — Sat, 14 Jan 2012 06:28:27 +0000

–>then you probably haven’t specified ‘-f’ in ‘inetd.conf’.
–>In releases prior to CVS 1.11.1, this problem can be caused by your system setting the $HOME environment variable for programs being run by xinetd. In this case, you can either have xinetd run a shell script that unsets $HOME and then runs CVS, or you can use env to run CVS with a pristine environment.

What are init 0, init 1, init 2 ,init 3, init 4, init 5, init 6, init s, init S

John McArthur — Thu, 17 Nov 2011 08:28:54 +0000

There are basically 8 runlevels in unix.
Run Level: At any given time, the system is in one of eight possible run levels. A run level is a software configuration under which only a selected group of processes exists. Processes spawned by init for each of these run levels are defined in /etc/inittab. init can be in one of eight run levels, 0-6 and S or s (S and s are identical). The run level changes when a privileged user runs /sbin/init.

init 0 : Shutdown (goes thru the /etc/rc0.d/* scripts then halts)
init 1 : Single user mode or emergency mode means no network no multitasking is present in this mode only root has access in this runlevel
init 2 : No network but multitasking support is present .
init 3 : Network is present multitasking is present but with out GUI .
init 4 : It is similar to runlevel 3; It is reserved for other purposes in research.
init 5 : Network is present multitasking and GUI is present with sound etc.
init 6 : This runlevel is defined to system restart.
init s : Tells the init command to enter the maintenance mode. When the
system enters maintenance mode from another run level, only the system console
is used as the terminal.
init S : Same as init s.
init m : Same as init s and init S.
init M : Same as init s or init S or init m.