Nowadays, I analyze the open source of blue DBM device driver source code.

Simple file structure of blue DBM Driver open source

Just this above URL is my information I arrange blue DBM driver open source. So I want to access the above URL, You can’t with the URL

just for your information, I attach here PDF

Basically, The above PDF is as follows :

The following shows you the simple information of above URL .

                 File System
                     |
                     |
               Robusta.ko(blue DBM driver)
                     |
                     |  
               DumbSSD.ko  // just this module is  for coversation with the original nvme dirver
                     |
            register | unregister  // here is just module register function
                     |
               Nvme driver(Nmve.ko)
                     |
                     |
               Device (SSD)

for the above information. you can understand information about basic structure of blueDBM file.

So, from now on, it is in detail to explain the blue DBM.

First, we have to see make file!!!. So you can know which one is important.

Let’s check up each of makefile in blueDBM

basically, You have to know about Makefile grammar of something.

So I recommand you this site abut Makefile to look up.

If you want to see information of the above URL, just take a look at this PDF file

Basically, this PDF file is as follows:

let’s summarize about Makefile’s rule.

Concept of Makefile

A Simple Makfile consists of “rules” with the following shape :

   target ... : prerequisites ...
               recipe
               ..... 
               .....
               .....

A target is usually the name of a file that is generated by a program; examples of targets are executable or object files. A target can also be the name of an action to carry out, such as ‘clean’

  • Phony Targets

A prerequisite is a fiel that is used as input to create the target. A target often depends on several files.

A recipe is an action that make carries out. A recipe may have more than one command, either on the same line. or each on its own line. Please note: you need to put a tab character at the beginning of every recipe line!.

Function flow of Mount_ext4.sh

First of all, You need to know device driver.

First, I recommend you this site that explain you about block device.

Block Device Architecture

Algorithm that sorts the I/O requests is called as the elevator algorithm.

Block devices are accessed as special type of files, such as /dev/sda1.

So block layer is elevator algorithm, because it make a group of contiguous setors consisting of multiple requesis.

The kernel identifies the device only with major number and minor number combination.

The major number is used to identify the device driver an minor number is used to identify the partition within the device.

This stores the information about a disk.

The important fields are queue, part and fops used to store the request queue, partition information and the block device operations table respectively.

the followings shows the information about structure of kernel.

first, gendisk

second, hd_struct in gendisk.

Third, block_device.

bdev_alloc_inode function is called to allocate the the above block device structure.

fourth, buffer_haed

fifth, bio

sixth, bio_vec this is important to manage the actual I/O data

seventh, request

eighth, request queue and in the structure, request_fn pointer.

when registering the driver, what function is important??

alloc_disk function -> add_disk function.

blk_init_queue function -> blk_init_queue_node function -> blk_queue_make_request.

In addition to the above block device, precedure to install filesystem.

what I first recommend is this site(writing-a-file-system-in-linux-kernel)

let’s see the simple code of kernel module.

below shows you in example code inside the above URL(writing-a-file-system-in-linux-kernel)

  #include <linux/init.h>
  #inlcude <linux/module.h>
  
  static int _init aufs_init(void) {
  
      pr_debug("aufs module loaded\n");
      return 0;
  }
  
  static void __exit aufs_fini(void) {
  
        pr_debug("aufs module unloeaded\n");
  }
  
  module_init(aufs_init);
  module_exit(aufs_fini);
  
  MODULE_LICENSE("GPL");
  MODULE_AUTHOR("kmu");

As you can see two headers at beginning of the above code.

these headers is important in any of loadable module.

Then two functions follow.

__init label is a hint to kernel that the function is used during module initializaion only.

If you want to know more, get a reference to this source(lxr)

So that means that after the module initialization it can be unloaded from memory.

Now, We are looking at another site about device driver(drivers_linux).

I strongly recommend you the site right above.

Finally, If you know the total story of kernel device driver, I recommed this site(tldp)

arragement of device driver of the above URL

the following article shows you about arrangement of the above URL(drivers_linux)

The user commands insmod and rmmod use the kernel space functions moudle_init and module_exit.