[kernel] two methods of driver compilation: compiling into modules and compiling into the kernel (using miscellaneous device driver templates)

Miscellaneous device driver code template

/********* These are the necessary header files **********/
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/miscdevice.h>
#include <linux/fs.h>
#include <linux/uaccess.h>

int misc_open(struct inode* inode, struct file *file)
{
    
	printk("[misc]open misc\n"); //  Turn on the device signal 
	return 0;
}

int misc_release(struct inode *inode, struct file *file)
{
    
	printk("[misc]release misc\n"); //  release device 
	return 0;
}

//  The application layer reads the drive layer signal 
ssize_t misc_read(struct inode *inode, char __user *ubuf, size_t size, loff_t *loff_t)
{
    
	char kbuf[128] = "kernel to user str";
	if(copy_to_user(ubuf, kbuf, sizeof(kbuf)) == 0)
	{
    
		printk("return data error");
	}
	return 0;
}

//  Applied as a write driver layer signal 
ssize_t misc_write(struct inode *inode, char __user *ubuf, size_t size, loff_t *loff_t)
{
    
	char kbuf[128];
	if(copy_from_user(kbuf,ubuf,size) == 0)
	{
    
		printk("[user to kernel]%s\r\n",kbuf);
	}
	return 0;
}

//  File operation structure 
struct file_operations misc_fops = {
    
	.owner = THIS_MODULE,
	.open = misc_open,
	.release = misc_release,
	.read = misc_read,
	.write = misc_write,
};


struct miscdevice misc_dev = {
    
	.minor = MISC_DYNAMIC_MINOR,//  The secondary equipment number is miscellaneous equipment 
	.name = "misc_mod", //  Device node name 
	.fops = &misc_fops //  Binding file operation structure pointer 
};

static int __init misc_init(void)
{
    
	int ret;
	ret = misc_register(&misc_dev);
	if(ret < 0)
	{
    
		printk("misc_dev register error\r\n");
		return -1;
	}
	return 0;
}

static void __exit misc_exit(void)
{
    
	misc_deregister(&misc_dev);
}

module_init(misc_init); //  Load initialization signal binding 
module_exit(misc_exit); //  Unload signal binding 

MODULE_AUTHOR("stylle"); //  author 
MODULE_DESCRIPTION("misc driver"); //  Driver introduction can be omitted 
MODULE_LICENSE("GPL");//  Open source licenses 

The driver of miscellaneous equipment is the simplest and most convenient in driver development , The core is to deal with write Signals and read Signals react accordingly .

Drivers are compiled into modules

If you need to compile a driver into a module, you must have a compiled kernel, And the development board is burning this version kernel, To compile a module, we just need to create a new one Makefile file ：

ARCH 				= arm  				# 32 position ：arm 64 position ：arm64
#  Cross compiler prefix   For example, I cross compile here gcc Namely arm-linux-gcc Fill in here  arm-linux-
CROSS_COMPILE		= aarch64-linux-gnu-  		
KDIR 				:= /home/qlqcetc/nuc977bsp/02.linux_kernel 		#  Compiled kernel path 
TARGET 				= misc  			#  Destination filename ：misc.ko
EXEC 				= $(TARGET)  
obj-m 				:=$(TARGET).o
PWD 				:=$(shell pwd)

all:
	$(MAKE) -C $(KDIR) M=$(PWD) modules

clean:
	rm -rf *.o *~core.depend.*.cmd *.ko *.mod.c .tmp_versions $(TARGET)

Then we just need to make Will generate .ko file , And then ko Copy the file to the development board , The load driver uses insmod、 Uninstall the kernel to use rmmod.

insmod misc.ko
ls /dev   #  Print the driver list to view our misc_mod Whether to load it 

rmmod misc
ls /dev #  It should disappear after uninstallation 

Drivers are compiled into the kernel

If you want to compile the driver into the kernel, you need to create two new files Makefile One Kconfig
Makefile

obj-$(CONFIG_MISC)		+= misc.o  # there misc.o The file name should correspond to itself .c File generated .o file name 

Kconfig

config MISC
	tristate "auto reg" #  The name displayed in the graphical configuration menu 
	depends on HELLO #  rely on HELLO  Modules can be selected 
	help
	  auto reg help #  Graphically configured help Prompt information 

dependent Kconfig The configuration also includes the following items ：

1. config MISC The name of the configuration option

2. tristate Indicates the state of the drive , The three states are compiling drivers into modules , Compile the driver into the kernel , Don't compile . Corresponding to it is also Yes bool They are compiled to the kernel , Don't compile

3. A depends on B Indicates that only when B You can only choose A For example, I want to get rid of LED Related drivers , We change it directly .config Is the file ok ？ Sure , But not recommended . If there is a dependency , Directly modifying .config It's not successful .

4. select Reverse dependency , When this option is selected , The following definitions will also be selected .

Then we need to modify the upper level directory Makefile And the one above Kconfig That is to say Kernel Under the driver In the catalog Makefile and Kconfig file

Makefile The change is to add the path where the driver is located
obj-y Means compiling into the kernel
obj-m Compiled into modules
obj-$ Indicates that you can select from the graphical configuration

Kconfig The change of is to add the drive under the path Kconfig file

Then enter kernel Use under root directory make menuconfig Command to enter the device driver configuration , There is also a point here that needs doctrine is this menu here menu The corresponding parameter is the parameter of our driving list

Because of what we have here Kconfig in source Fill in at the end, so the options here should also be at the end , Then we can use the space to select the driver compilation ：

* Means to compile into the kernel
M Compiled into modules