Linux hard link and soft link Linux ASM file

When I read the embedded Linux LED driver today

The driver implementation part is clear.

But the paths of several header files really confuse me. the Linux 2.6.13 file is organized as follows:

The header file is as follows:

#include <asm/irq.h>#include <asm/arch/regs-gpio.h>#include <asm/hardware.h>

But I cannot find the ASM folder corresponding to the arm, or the corresponding directory does not correspond to the s3c24xx folder.

Later, I accidentally read an article about the link instance in kernel porting.

So the ASM file should also be a connection, so everything is okay.

Connect the ASM file to the \ kernel-2.6.13 \ include \ ASM-arm folder

# Include <ASM/IRQ. h >=\ kernel-2.6.13 \ include \ ASM-Arm \ IRQ. h
# Include <ASM/ARCH/regs-gpio.h> = kernel-2.6.13 \ include \ ASM-Arm \ arch-s3c2410 \ regs-gpio.h
# Include <ASM/hardware. h >=\ kernel-2.6.13 \ include \ ASM-Arm \ hardware. h

So I guess if you see

# Include <Mach/regs-gpio.h>

It may mean

Mach = kernel-2.6.13 \ arch \ Arm \ mach-s3c2410

# Include <Linux/interrupt. h> operating system interruption # include <ASM/uaccess. h> processor-related entry // # include <ASM/ARCH/regs-gpio.h> processor-related IO port operations # include <Mach/regs-gpio.h> same as above // # include <ASM/ hardware. h> processor-related hardware # include <Mach/hardware. h> same as above

Http://www.cnblogs.com/sonic4x/archive/2011/08/05/2128543.html
Linux hard link and soft link

1. Linux link concept
Linux links are classified into two types: hard link and symbolic link ). By default, the ln command generates a hard link.

[Hard connection]
Hard connection refers to the connection through the index node. In a Linux File System, a file stored in a disk partition is assigned with an index node number (inode index) No matter what type it is ). In Linux, multiple file names direct to the same index node. Generally, this type of connection is hard connection. A hard connection allows a file to have multiple valid path names. In this way, you can create a hard connection to an important file to prevent "accidental deletion. The reason is as described above, because there is more than one connection to the index node of the directory. Deleting only one connection does not affect the connection between the index node and other nodes. Only when the last connection is deleted will the connection of the data block and directory of the file be released. That is to say, the true condition for deleting a file is that all hard connection files related to the file are deleted.

Two hard connection restrictions:

L hard links cannot be created for directories

L a link can be created only between files in the same file system. That is, hard links cannot be established between two files in different hard disk partitions. This is because the hard link points to the original file through the node, and the file I-node may be different in different file systems.

 

[Soft connection]
Another connection is also called symbolic link. Soft-link files have shortcuts similar to Windows. It is actually a special file. In a symbolic connection, a file is actually a text file containing the location information of another file.

This allows symbolic links (often abbreviated as symlinks) to point to a file located in another partition or even on another network hard disk.

 

2. Deepen understanding through experiments
[Oracle @ Linux] $ touch F1 # create a test file F1
[Oracle @ Linux] $ ln F1 F2 # create a hard connection file F2 of F1
[Oracle @ Linux] $ ln-s F1 F3 # create a symbolic connection file F3 for F1
[Oracle @ Linux] $ LS-li #-I parameter displays inode node information of the file
Total 0
9797648-RW-r -- 2 Oracle oinstall 0 Apr 21 08:11 F1
9797648-RW-r -- 2 Oracle oinstall 0 Apr 21 08:11 F2
9797649 lrwxrwxrwx 1 Oracle oinstall 2 Apr 21 F3-> F1

From the above results, we can see that the hard connection file F2 is the same as the inode node of the original file F1, both of which are 9797648. However, the inode node of the symbolic connection file is different.

[Oracle @ Linux] $ echo "I am F1 file"> F1
[Oracle @ Linux] $ cat F1
I am F1 File
[Oracle @ Linux] $ cat F2
I am F1 File
[Oracle @ Linux] $ cat F3
I am F1 File
[Oracle @ Linux] $ Rm-F F1
[Oracle @ Linux] $ cat F2
I am F1 File
[Oracle @ Linux] $ cat F3
Cat: F3: no such file or directory

The test above shows that after the original file F1 is deleted, the hard connection F2 is not affected, but the symbolic connection F3 file is invalid.

3. Summary
Therefore, you can perform related tests and draw the following conclusions:
1) Delete the symbol to connect to F3, which has no effect on F1 and F2;
2). Deleting a hard connection F2 does not affect F1 or F3;
3) deleting the original file F1 does not affect the hard connection F2, resulting in invalid symbolic connection F3;
4). Delete the original file F1 at the same time and hard connect F2. The entire file will be deleted.

Below is a simple LED driver instance

Http://blog.mcuol.com/User/gaochengnan/Article/13406_1.htm

For more information, see

Http://hi.baidu.com/tekuba/item/d72e32eb8f19713d86d9de94

Http://longer.spaces.eepw.com.cn/articles/article/item/60415

LED driver experiment source code gaoled. c: # include "Linux/config. H "# include" Linux/module. H "# include" Linux/kernel. H "# include" Linux/Fs. H "# include" Linux/init. H "# include" Linux/devfs_fs_kernel.h "# include" Linux/miscdevice. H "# include" Linux/delay. H "# include" ASM/IRQ. H "# include" ASM/ARCH/The regs-gpio.h "# include" ASM/hardware. H "# define device_name" gcnled "// define the device name # define led_major 250 // manually define the master device number module_author (" GCN "); module_de Scription ("S3C2440 LED driver"); module_license ("GPL"); // defines the device to operate, use each led as a member of the struct static unsigned long led_table [] = {s3c2410_gpf4, s3c2410_gpf5, s3c2410_gpf6, s3c2410_gpf7,}; // you can set the device, five pins are output ports static unsigned int led_pai_table [] = {s3c2410_gpf4_outp, s3c2410_gpf5_outp, s3c2410_gpf6_outp, expires,}./* write the function of s3c2440_led_ioctl: the device driver manages the device's I/O channels to perform led operations */is the core of the entire driver */static int S3 C2440_leds_ioctl (struct inode * inode, struct file * file, unsigned int cmd, unsigned long Arg) {If (Arg> 3) {return-einval;} led (CMD) {Case 0: Case 1: s3c2410_gpio_setpin (led_table [Arg],! CMD); Return 0; default: Return-einval ;}// defines s3c2440_led_fops: the entry point of the basic function provided by the struct: static struct file_operations s3c2440_leds_fops = {. owner = this_module ,. IOCTL = s3c2440_leds_ioctl,}; // module Loading Function static int _ init s3c2440_leds_init (void) {int ret; int I; // register the device number/* register_chrdev is the function for registering character devices */ret = register_chrdev (led_major, device_name, & s3c2440_leds_fops); If (Ret <0) {printk (device_name "Can '''''''''''''''' ''''' ''' T register major number \ n "); return ret;}/* 2.6 After kernel driver registration, use the following code to create a device file */devfs_mk_cdev (mkdev (led_major, 0), s_ifchr | s_irusr | s_iwusr | s_irgrp, device_name); for (I = 0; I <4; I ++) {s3c2410_gpio_cfgpin (led_table [I], led_cfg_table [I]);/* is equivalent to setting the corresponding port as the output port */s3c2410_gpio_setpin (led_table [I], 1);/* set port to 1 */} printk (device_name "initialized \ n");/* print the information about successful driver loading */return 0 ;} // module unmount function static v Oid _ exit s3c2440_leds_exit (void) {devfs_remove (device_name);/* 2.6 The kernel driver must use the following code to remove the device file */unregister_chrdev (led_major, device_name );} // specify the initialization and uninstallation functions of the driver module_init (s3c2440_leds_init); module_exit (s3c2440_leds_exit. c. Enter the/devices/Char directory in the kernel directory to modify the makefile: obj-M + = gaoled. O running make modules in the kernel root directory will find that gaoled is generated. the Ko file then implements gaoled. ko is transferred to the Development Board (I used the USB flash drive to test it and mount it on the Development Board) on gaoled. run insmod gaoled in the C directory. ko prints gcnled ini Tialized successful! Run cat devices in/proc on the Development Board to check whether the program is successful. Note: compile and generate the. Ko file on the PC. Then the module insmod XXX. Ko is loaded on the Development Board. The problem occurs: The devices busy device is busy or something, because the master device number is repeated! After I changed 231 to 250 at the beginning, all of the above steps passed the test procedure.