Chatting with the input device in Linux (5) her eyes

The story is about to enter the climax. Next, let's take a look at where the girl was married.

The real executor is the input_register_device () function.

Also from the input core, let's take a look at her full picture:

Int input_register_device (struct input_dev * Dev)

{

1 static atomic_t input_no = atomic_init (0 );

2 struct input_handler * Handler;

3 const char * path;

4 int error;

 

5 _ set_bit (ev_syn, Dev-> evbit );

 

/*

* If delay and period are pre-set by the driver, then autorepeating

* Is handled by the driver itself and we don't do it in input. C.

*/

 

6 init_timer (& Dev-> timer );

7 if (! Dev-> rep [rep_delay] &! Dev-> rep [rep_period]) {

8 Dev-> timer. Data = (long) Dev;

9 Dev-> timer. Function = input_repeat_key;

10 Dev-& gt; rep [rep_delay] = 250;

11 Dev-> rep [rep_period] = 33;

12}

 

13 if (! Dev-> getkeycode)

14 Dev-> getkeycode = input_default_getkeycode;

 

15 if (! Dev-> setkeycode)

16 Dev-> setkeycode = input_default_setkeycode;

 

17 snprintf (Dev-> Dev. bus_id, sizeof (Dev-> Dev. bus_id ),

18 "input % lD", (unsigned long) atomic_inc_return (& input_no)-1 );

 

19 error = device_add (& Dev-> Dev );

20 if (error)

21 return error;

 

22 Path = kobject_get_path (& Dev-> Dev. kobj, gfp_kernel );

23 printk (kern_info "input: % s as % s/n ",

24 Dev-> name? Dev-> name: "unspecified device", path? Path: "N/");

25 kfree (PATH );

 

26Error = mutex_lock_interruptible (& input_mutex );

27 if (error ){

28 device_del (& Dev-> Dev );

29 return error;

}

 

30 list_add_tail (& Dev-> node, & input_dev_list );

 

31 list_for_each_entry (handler, & input_handler_list, node)

32 input_attach_handler (Dev, Handler );

 

33 input_wakeup_procfs_readers ();

 

34Mutex_unlock (& input_mutex );

 

35 return 0;

}

Here, when I show the number of lines of code, only the lines with code are marked for convenience. For empty lines, it is omitted.

Lines 1-4 initialize some basic variables for later use. Here we will focus on the static atomic_t input_no = atomic_init (0); here atomic_t indicates an atomic variable. Remember that for atomic variables, they cannot be accessed concurrently. For example, if two threads want to add 1 to nput_no, if the initial value of input_no is 0, when the two threads access it serially, of course, we can get the expected value 2. If it is concurrency, the two threads access it at the same time. The obtained initial values are both 0 and 1 is added to her at the same time, the last value we see is added only once, that is, 1. Atomic variables solve such problems. Each time, only one thread can obtain it, perform operations, release it, access it from the second thread, and release it. Does it make you think of the spin lock mechanism, smart, it is a simplified version of the spin lock, but the operation object is a variable, not a piece of critical code.

Five rows. Set ev_syn so that all devices can support it.

Lines 6-18 are related to the buttons and are irrelevant to us. Temporarily.

19 rows of error = device_add (& Dev-> Dev); and device_initialize (& Dev-> Dev) in 4 Summary; husband and singer, let's register the embedded Dev structure in our input device in the system, and form a corresponding File hierarchy in the sysfs file system.

Lines 20-25 print the path of the device in the file system.

26 and 34 lines of code are designed to prevent the code in the intermediate critical section from being accessed concurrently. Do you remember where he initialized it? In the input_allocate_device function in section 4th, the original sentence is mutex_init (& Dev-> mutex). Why should mutex be used, this issue is left to the critical section code in the middle of the analysis for further discussion. Here, mutex_lock_interruptible () is replaced by mutex_lock. The former indicates that it can be interrupted by signals, while the latter obviously does not.

Line 27-29 Code. If the process does not obtain the mutex, it means another program occupies her. Dude, you are born to lose your life. All your work, flowers, and movies are busy, give up everything (device_del (& Dev-> Dev);), go back to your hometown, and then slowly lie at home and wait, wait for the old guy, wait for the day he let go ......

30-33 rows, very lucky, she is still alone, also waiting for you to appear, so I agree and, with no guesses, continue to hand down... Line 30: add the device to input_dev_list. Line 31 traverses all registered handler linked lists in the system, that is, input_handler_list. right .. OK. All functions are successfully returned. The input device is successfully married, and the task is completed. The brother of the net name "Simon brag" said something, as if something was missing? Oh, yes! As mentioned above, why does mutex need to be used to prevent concurrent access to this code? If you still ask me this question, I will scold you. Are you reading my documents?

The story is about to enter the climax. Next, let's take a look at where the girl was married.

The real executor is the input_register_device () function.

Also from the input core, let's take a look at her full picture:

Int input_register_device (struct input_dev * Dev)

{

1 static atomic_t input_no = atomic_init (0 );

2 struct input_handler * Handler;

3 const char * path;

4 int error;

 

5 _ set_bit (ev_syn, Dev-> evbit );

 

/*

* If delay and period are pre-set by the driver, then autorepeating

* Is handled by the driver itself and we don't do it in input. C.

*/

 

6 init_timer (& Dev-> timer );

7 if (! Dev-> rep [rep_delay] &! Dev-> rep [rep_period]) {

8 Dev-> timer. Data = (long) Dev;

9 Dev-> timer. Function = input_repeat_key;

10 Dev-& gt; rep [rep_delay] = 250;

11 Dev-> rep [rep_period] = 33;

12}

 

13 if (! Dev-> getkeycode)

14 Dev-> getkeycode = input_default_getkeycode;

 

15 if (! Dev-> setkeycode)

16 Dev-> setkeycode = input_default_setkeycode;

 

17 snprintf (Dev-> Dev. bus_id, sizeof (Dev-> Dev. bus_id ),

18 "input % lD", (unsigned long) atomic_inc_return (& input_no)-1 );

 

19 error = device_add (& Dev-> Dev );

20 if (error)

21 return error;

 

22 Path = kobject_get_path (& Dev-> Dev. kobj, gfp_kernel );

23 printk (kern_info "input: % s as % s/n ",

24 Dev-> name? Dev-> name: "unspecified device", path? Path: "N/");

25 kfree (PATH );

 

26Error = mutex_lock_interruptible (& input_mutex );

27 if (error ){

28 device_del (& Dev-> Dev );

29 return error;

}

 

30 list_add_tail (& Dev-> node, & input_dev_list );

 

31 list_for_each_entry (handler, & input_handler_list, node)

32 input_attach_handler (Dev, Handler );

 

33 input_wakeup_procfs_readers ();

 

34Mutex_unlock (& input_mutex );

 

35 return 0;

}

Here, when I show the number of lines of code, only the lines with code are marked for convenience. For empty lines, it is omitted.

Lines 1-4 initialize some basic variables for later use. Here we will focus on the static atomic_t input_no = atomic_init (0); here atomic_t indicates an atomic variable. Remember that for atomic variables, they cannot be accessed concurrently. For example, if two threads want to add 1 to nput_no, if the initial value of input_no is 0, when the two threads access it serially, of course, we can get the expected value 2. If it is concurrency, the two threads access it at the same time. The obtained initial values are both 0 and 1 is added to her at the same time, the last value we see is added only once, that is, 1. Atomic variables solve such problems. Each time, only one thread can obtain it, perform operations, release it, access it from the second thread, and release it. Does it make you think of the spin lock mechanism, smart, it is a simplified version of the spin lock, but the operation object is a variable, not a piece of critical code.

Five rows. Set ev_syn so that all devices can support it.

Lines 6-18 are related to the buttons and are irrelevant to us. Temporarily.

19 rows of error = device_add (& Dev-> Dev); and device_initialize (& Dev-> Dev) in 4 Summary; husband and singer, let's register the embedded Dev structure in our input device in the system, and form a corresponding File hierarchy in the sysfs file system.

Lines 20-25 print the path of the device in the file system.

26 and 34 lines of code are designed to prevent the code in the intermediate critical section from being accessed concurrently. Do you remember where he initialized it? In the input_allocate_device function in section 4th, the original sentence is mutex_init (& Dev-> mutex). Why should mutex be used, this issue is left to the critical section code in the middle of the analysis for further discussion. Here, mutex_lock_interruptible () is replaced by mutex_lock. The former indicates that it can be interrupted by signals, while the latter obviously does not.

Line 27-29 Code. If the process does not obtain the mutex, it means another program occupies her. Dude, you are born to lose your life. All your work, flowers, and movies are busy, give up everything (device_del (& Dev-> Dev);), go back to your hometown, and then slowly lie at home and wait, wait for the old guy, wait for the day he let go ......

30-33 rows, very lucky, she is still alone, also waiting for you to appear, so I agree and, with no guesses, continue to hand down... Line 30: add the device to input_dev_list. Line 31 traverses all registered handler linked lists in the system, that is, input_handler_list. right .. OK. All functions are successfully returned. The input device is successfully married, and the task is completed. The brother of the net name "Simon brag" said something, as if something was missing? Oh, yes! As mentioned above, why does mutex need to be used to prevent concurrent access to this code? If you still ask me this question, I will scold you. Are you reading my documents?