linux入力サブシステム分析
22068 ワード
まずhandlerの分析から、登録したhandlerにはそれらがあることを見てみましょう.joydev.c(レバーイベント)、mousedev.c(マウスイベント)、evdev.c(汎用タッチパネル、ボタン、sensorなどのイベント)、keyboard.c(usb,ps 2キーボードイベント)、ここで最もよく使われるevdevを選択します.c分析、drivers/input/evdev.c中:
1003行eventは、そのhandlerがイベントを処理する能力を表し、そのhandlerに登録されたタッチスクリーン、ボタン、sensorなどのレポートイベントは、それを介して処理され、ユーザ空間に報告される.まず1014行から始めます.
1947行はNULLではないのでinput_handlerをinput_に配置table配列でinput_tableの定義とhandler->minorの値は次のとおりです.
static struct input_handler *input_table[8];
#define EVDEV_MINOR_BASE 64
input_からtable配列の大きさは、linuxサブシステムが最大8つのhandlerを登録できることを見ることができます.では、handlerごとに何つのデバイスを処理することができますか.minor>5と関係がありますか.32ですか.続いて下を見るとわかります.次に1955行、handlerをinput_に追加しますhandler_リストチェーンテーブル、input_handler_Listチェーンテーブルは、入力サブシステムに登録されているhandlerをすべて維持します.1957行、input_dev_リストは登録されたすべてのinput_devチェーンテーブル(後で見ます)、list_for_each_entryはすべてのinputを遍歴しますdev、これらのinputを見てください.devがhandlerと一致するかどうか、ここではinput_と仮定します.handlerが先に登録した、すべてのinput_devはまだ登録されていないので、ここinput_dev_リストが空です.input_register_handler登録が完了しました.
次にinput_を見てみましょうdevの登録プロセスでは、drivers/input/keyboard/imapx 800_で特定のキーイベント分析を行います.gpio.c中:
527行、ここのdev.parentは&pdev->devを指し、pdevはplatform_であるデバイス、354行の重点部分を見てください.
1885行、input_devをinput_に掛けますdev_Listチェーンテーブルでは、このチェーンテーブルの前にhandlerを登録したときに遭遇したことがあるので、handlerを先に登録してもinput_を登録してもdevは、相手のチェーンテーブルを巡ってマッチングします.ポイントの1887行を見て、ここのinput_handler_リストに掛けられているのは前のevdevです.cのhandlerには、もちろん他のhandler、例えばゲームレバーなどがあるかもしれません.Input_に入りますattach_handler関数:
913行のinput_match_デバイスマッチングルール:
ここ873行のhandler->id_tableはevdevである.c中input_handler構造体が指す:
id->flagsが0、id->driver_infoは1なので、前のif条件は成立しません.901行まで、ここでhandler->matchは空なので、このid、すなわちhandler->id_を返します.table.次にhandler->connect(handler,dev,id)はhandler構造体におけるconnectが指す関数を呼び出し、ここでevdev.cに定義があるので、この関数に入ります.
929行、ここのEVDEV_MINORSは次のように定義されています.
#define EVDEV_MINORS 32
ここでinput_dev evdev_に追加table配列の933行でinput_を追加するとdevが32を超えると追加を続けることができず、このhandlerが最も32のデバイスしか掛けられないことを示し、前の推測が正しいことも確認された.
938行は、メンバーinput_を持つevdev構造体を作成します.handle、handlerとinputを接続するために使用されるhandledev、951行と953行から見ると、彼はhandlerとinputを保存しています.devの場所は後で検索するために
956行は、デバイスノードのプライマリデバイスとスレーブデバイス番号を作成し、この入力サブシステムに掛けられているプライマリデバイス番号は同じであり、デバイス番号から0〜255なので、入力サブシステムは最大256個のデバイスを掛けることができる.
続いて962行は,handleをinputサブシステムに登録する.996行evdev_install_chrdevはevdevを後で使用するために保存します.
970 device_経由add後、dev/inputディレクトリの下にノードが表示されます.event 0、event 1、event 2、event 3など、番号は登録順に947行増加します.
次に、データのレポート処理を見て、dev/input/event 0などのデバイスノードを上位レベルで開き、この処理を見てみましょう.ユーザ空間open後、drivers/input/inputを呼び出す.cのfile_operationsのopen:
2117行、iminor(inode)はevdevのためデバイス番号を見つけた.cのhandlerスレーブ番号はEVDEV_MINOR_BASE+minor、うちminorは0～31、EVDEV_MINOR_BASEは64なので、デバイス番号>>5から1で、前のevdevを見つけました.cに登録されているhandler.
2119行、handlerのfileを取得operations構造体;2136行、openをhandlerのfile_に向けますoperationsのopen.ここから分かるようにinput.cのopenはコールバック関数の役割を果たしただけで、最後にコールバックがそれぞれhandler自身で実現したfile_operationsのopen関数.だからevdevに入ります.c中:
297行、evdev_tableは前のconnect関数で分析しましたevdev_install_chrdev関数に保存されているここではminorの値に基づいて対応するevdevを取り出し、evdevのhanleに基づいて対応するinput_を見つけることができます.dev.307行は、報告されたデータを保存するメカニズムを作成し、その後分析され、321行evdev_attach_クライアントとは、クライアントをクライアントに追加することです.Listチェーンテーブルでは、323行でopenの処理を行い、open操作が完了します.
次にユーザ空間はread,poll,ioctlなどの操作を呼び出して過去のイベントに来て、androidが最もよく使うpoll+readメソッドを見て、最終的にevdevを呼び出します.cのfile_operationsでpoll:
439行に示すように、poll操作はここでブロックされ、最下位のレポート・イベントの起動を待つ.次に、最下位のイベントの報告を見てみましょう.前のdrivers/input/keyboard/imapx 800_です.gpio.c中:
input_event(ptr->input, EV_KEY, ptr->code, 0);
input_sync(ptr->input);
詳細なオーバーレイヤはここでは分析されず、handlerのeventメソッドが呼び出されます.
104～108行対input_event構造体は、最終的にデータを報告する構造体、114行、最終的にkillを呼び出す値を付与する.fasync(&client->fasync,SIGIO,POLL_IN)は異ユーザ空間を起動異ユーザ空間を起動するステップ読み取りイベントを待つプロセスを使用し、これはアクティブにユーザ空間を起動する方法であり、122行は、前ユーザ空間pollのブロックを起動するので、前のpollがブロックしている場所に戻って、poll_waitはすでに起動され、ユーザー空間はデータが報告されたことを知っていて、それからreadを呼び出してデータを読み出して、このようにfile_を呼び出しましたoperationsのevdev_read:
1002 static struct input_handler evdev_handler = {
1003 .event = evdev_event,
1004 .connect = evdev_connect,
1005 .disconnect = evdev_disconnect,
1006 .fops = &evdev_fops,
1007 .minor = EVDEV_MINOR_BASE,
1008 .name = "evdev",
1009 .id_table = evdev_ids,
1010 };
1011
1012 static int __init evdev_init(void)
1013 {
1014 return input_register_handler(&evdev_handler);
1015 }1003行eventは、そのhandlerがイベントを処理する能力を表し、そのhandlerに登録されたタッチスクリーン、ボタン、sensorなどのレポートイベントは、それを介して処理され、ユーザ空間に報告される.まず1014行から始めます.
1936 int input_register_handler(struct input_handler *handler)
1937 {
1938 struct input_dev *dev;
1939 int retval;
1940
1941 retval = mutex_lock_interruptible(&input_mutex);
1942 if (retval)
1943 return retval;
1944
1945 INIT_LIST_HEAD(&handler->h_list);
1946
1947 if (handler->fops != NULL) {
1948 if (input_table[handler->minor >> 5]) {
1949 retval = -EBUSY;
1950 goto out;
1951 }
1952 input_table[handler->minor >> 5] = handler;
1953 }
1954
1955 list_add_tail(&handler->node, &input_handler_list);
1956
1957 list_for_each_entry(dev, &input_dev_list, node)
1958 input_attach_handler(dev, handler);
1959
1960 input_wakeup_procfs_readers();
1961
1962 out:
1963 mutex_unlock(&input_mutex);
1964 return retval;
1965 } 1947行はNULLではないのでinput_handlerをinput_に配置table配列でinput_tableの定義とhandler->minorの値は次のとおりです.
static struct input_handler *input_table[8];
#define EVDEV_MINOR_BASE 64
input_からtable配列の大きさは、linuxサブシステムが最大8つのhandlerを登録できることを見ることができます.では、handlerごとに何つのデバイスを処理することができますか.minor>5と関係がありますか.32ですか.続いて下を見るとわかります.次に1955行、handlerをinput_に追加しますhandler_リストチェーンテーブル、input_handler_Listチェーンテーブルは、入力サブシステムに登録されているhandlerをすべて維持します.1957行、input_dev_リストは登録されたすべてのinput_devチェーンテーブル(後で見ます)、list_for_each_entryはすべてのinputを遍歴しますdev、これらのinputを見てください.devがhandlerと一致するかどうか、ここではinput_と仮定します.handlerが先に登録した、すべてのinput_devはまだ登録されていないので、ここinput_dev_リストが空です.input_register_handler登録が完了しました.
次にinput_を見てみましょうdevの登録プロセスでは、drivers/input/keyboard/imapx 800_で特定のキーイベント分析を行います.gpio.c中:
struct input_dev *input;
input = input_allocate_device();
525 input->name = "imap-gpio";
526 input->phys = "imap-gpio/input0";
527 input->dev.parent = &pdev->dev;
528
529 input->id.bustype = BUS_HOST;
530 input->id.vendor = 0x0001;
531 input->id.product = 0x0001;
532 input->id.version = 0x0100;
533
534 error = input_register_device(input); 1660 struct input_dev *input_allocate_device(void)
1661 {
1662 struct input_dev *dev;
1663
1664 dev = kzalloc(sizeof(struct input_dev), GFP_KERNEL);
1665 if (dev) {
1666 dev->dev.type = &input_dev_type;
1667 dev->dev.class = &input_class;
1668 device_initialize(&dev->dev);
1669 mutex_init(&dev->mutex);
1670 spin_lock_init(&dev->event_lock);
1671 INIT_LIST_HEAD(&dev->h_list);
1672 INIT_LIST_HEAD(&dev->node);
1673
1674 __module_get(THIS_MODULE);
1675 }
1676
1677 return dev;
1678 } 527行、ここのdev.parentは&pdev->devを指し、pdevはplatform_であるデバイス、354行の重点部分を見てください.
int input_register_device(struct input_dev *dev)
{
........................
1866 dev_set_name(&dev->dev, "input%ld",
1867 (unsigned long) atomic_inc_return(&input_no) - 1);
1868
1869 error = device_add(&dev->dev);
1870 if (error)
1871 return error;
1872
1873 path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL);
1874 pr_info("%s as %s
",
1875 dev->name ? dev->name : "Unspecified device",
1876 path ? path : "N/A");
1877 kfree(path);
1878
1879 error = mutex_lock_interruptible(&input_mutex);
1880 if (error) {
1881 device_del(&dev->dev);
1882 return error;
1883 }
1884
1885 list_add_tail(&dev->node, &input_dev_list);
1886
1887 list_for_each_entry(handler, &input_handler_list, node)
1888 input_attach_handler(dev, handler);
....................
}1885行、input_devをinput_に掛けますdev_Listチェーンテーブルでは、このチェーンテーブルの前にhandlerを登録したときに遭遇したことがあるので、handlerを先に登録してもinput_を登録してもdevは、相手のチェーンテーブルを巡ってマッチングします.ポイントの1887行を見て、ここのinput_handler_リストに掛けられているのは前のevdevです.cのhandlerには、もちろん他のhandler、例えばゲームレバーなどがあるかもしれません.Input_に入りますattach_handler関数:
908 static int input_attach_handler(struct input_dev *dev, struct input_handler *handler)
909 {
910 const struct input_device_id *id;
911 int error;
912
913 id = input_match_device(handler, dev);
914 if (!id)
915 return -ENODEV;
916
917 error = handler->connect(handler, dev, id);
918 if (error && error != -ENODEV)
919 pr_err("failed to attach handler %s to device %s, error: %d
",
920 handler->name, kobject_name(&dev->dev.kobj), error);
921
922 return error;
923 }913行のinput_match_デバイスマッチングルール:
867 static const struct input_device_id *input_match_device(struct input_handler *handler,
868 struct input_dev *dev)
869 {
870 const struct input_device_id *id;
871 int i;
872
873 for (id = handler->id_table; id->flags || id->driver_info; id++) {
874
875 if (id->flags & INPUT_DEVICE_ID_MATCH_BUS)
876 if (id->bustype != dev->id.bustype)
877 continue;
878
879 if (id->flags & INPUT_DEVICE_ID_MATCH_VENDOR)
880 if (id->vendor != dev->id.vendor)
881 continue;
882
883 if (id->flags & INPUT_DEVICE_ID_MATCH_PRODUCT)
884 if (id->product != dev->id.product)
885 continue;
886
887 if (id->flags & INPUT_DEVICE_ID_MATCH_VERSION)
888 if (id->version != dev->id.version)
889 continue;
890
891 MATCH_BIT(evbit, EV_MAX);
892 MATCH_BIT(keybit, KEY_MAX);
893 MATCH_BIT(relbit, REL_MAX);
894 MATCH_BIT(absbit, ABS_MAX);
895 MATCH_BIT(mscbit, MSC_MAX);
896 MATCH_BIT(ledbit, LED_MAX);
897 MATCH_BIT(sndbit, SND_MAX);
898 MATCH_BIT(ffbit, FF_MAX);
899 MATCH_BIT(swbit, SW_MAX);
900
901 if (!handler->match || handler->match(handler, dev))
902 return id;
903 }
904
905 return NULL;
906 }ここ873行のhandler->id_tableはevdevである.c中input_handler構造体が指す:
995 static const struct input_device_id evdev_ids[] = {
996 { .driver_info = 1 }, /* Matches all devices */
997 { }, /* Terminating zero entry */
998 };id->flagsが0、id->driver_infoは1なので、前のif条件は成立しません.901行まで、ここでhandler->matchは空なので、このid、すなわちhandler->id_を返します.table.次にhandler->connect(handler,dev,id)はhandler構造体におけるconnectが指す関数を呼び出し、ここでevdev.cに定義があるので、この関数に入ります.
922 static int evdev_connect(struct input_handler *handler, struct input_dev *dev,
923 const struct input_device_id *id)
924 {
925 struct evdev *evdev;
926 int minor;
927 int error;
928
929 for (minor = 0; minor < EVDEV_MINORS; minor++)
930 if (!evdev_table[minor])
931 break;
932
933 if (minor == EVDEV_MINORS) {
934 pr_err("no more free evdev devices
");
935 return -ENFILE;
936 }
937
938 evdev = kzalloc(sizeof(struct evdev), GFP_KERNEL);
939 if (!evdev)
940 return -ENOMEM;
941
942 INIT_LIST_HEAD(&evdev->client_list);
943 spin_lock_init(&evdev->client_lock);
944 mutex_init(&evdev->mutex);
945 init_waitqueue_head(&evdev->wait);
946
947 dev_set_name(&evdev->dev, "event%d", minor);
948 evdev->exist = true;
949 evdev->minor = minor;
950
951 evdev->handle.dev = input_get_device(dev);
952 evdev->handle.name = dev_name(&evdev->dev);
953 evdev->handle.handler = handler;
954 evdev->handle.private = evdev;
955
956 evdev->dev.devt = MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + minor);
957 evdev->dev.class = &input_class;
958 evdev->dev.parent = &dev->dev;
959 evdev->dev.release = evdev_free;
960 device_initialize(&evdev->dev);
961
962 error = input_register_handle(&evdev->handle);
963 if (error)
964 goto err_free_evdev;
965
966 error = evdev_install_chrdev(evdev);
967 if (error)
968 goto err_unregister_handle;
969
970 error = device_add(&evdev->dev);
971 if (error)
972 goto err_cleanup_evdev;
973
974 return 0;
975
976 err_cleanup_evdev:
977 evdev_cleanup(evdev);
978 err_unregister_handle:
979 input_unregister_handle(&evdev->handle);
980 err_free_evdev:
981 put_device(&evdev->dev);
982 return error;
983 }929行、ここのEVDEV_MINORSは次のように定義されています.
#define EVDEV_MINORS 32
ここでinput_dev evdev_に追加table配列の933行でinput_を追加するとdevが32を超えると追加を続けることができず、このhandlerが最も32のデバイスしか掛けられないことを示し、前の推測が正しいことも確認された.
938行は、メンバーinput_を持つevdev構造体を作成します.handle、handlerとinputを接続するために使用されるhandledev、951行と953行から見ると、彼はhandlerとinputを保存しています.devの場所は後で検索するために
956行は、デバイスノードのプライマリデバイスとスレーブデバイス番号を作成し、この入力サブシステムに掛けられているプライマリデバイス番号は同じであり、デバイス番号から0〜255なので、入力サブシステムは最大256個のデバイスを掛けることができる.
続いて962行は,handleをinputサブシステムに登録する.996行evdev_install_chrdevはevdevを後で使用するために保存します.
871 static int evdev_install_chrdev(struct evdev *evdev)
872 {
873 /*
874 * No need to do any locking here as calls to connect and
875 * disconnect are serialized by the input core
876 */
877 evdev_table[evdev->minor] = evdev;
878 return 0;
879 }970 device_経由add後、dev/inputディレクトリの下にノードが表示されます.event 0、event 1、event 2、event 3など、番号は登録順に947行増加します.
次に、データのレポート処理を見て、dev/input/event 0などのデバイスノードを上位レベルで開き、この処理を見てみましょう.ユーザ空間open後、drivers/input/inputを呼び出す.cのfile_operationsのopen:
2146 static const struct file_operations input_fops = {
2147 .owner = THIS_MODULE,
2148 .open = input_open_file,
2149 .llseek = noop_llseek,
2150 }; 2106 static int input_open_file(struct inode *inode, struct file *file)
2107 {
2108 struct input_handler *handler;
2109 const struct file_operations *old_fops, *new_fops = NULL;
2110 int err;
2111
2112 err = mutex_lock_interruptible(&input_mutex);
2113 if (err)
2114 return err;
2115
2116 /* No load-on-demand here? */
2117 handler = input_table[iminor(inode) >> 5];
2118 if (handler)
2119 new_fops = fops_get(handler->fops);
2120
2121 mutex_unlock(&input_mutex);
2122
2123 /*
2124 * That's _really_ odd. Usually NULL ->open means "nothing special",
2125 * not "no device". Oh, well...
2126 */
2127 if (!new_fops || !new_fops->open) {
2128 fops_put(new_fops);
2129 err = -ENODEV;
2130 goto out;
2131 }
2132
2133 old_fops = file->f_op;
2134 file->f_op = new_fops;
2135
2136 err = new_fops->open(inode, file);
2137 if (err) {
2138 fops_put(file->f_op);
2139 file->f_op = fops_get(old_fops);
2140 }
2141 fops_put(old_fops);
2142 out:
2143 return err;
2144 }2117行、iminor(inode)はevdevのためデバイス番号を見つけた.cのhandlerスレーブ番号はEVDEV_MINOR_BASE+minor、うちminorは0～31、EVDEV_MINOR_BASEは64なので、デバイス番号>>5から1で、前のevdevを見つけました.cに登録されているhandler.
2119行、handlerのfileを取得operations構造体;2136行、openをhandlerのfile_に向けますoperationsのopen.ここから分かるようにinput.cのopenはコールバック関数の役割を果たしただけで、最後にコールバックがそれぞれhandler自身で実現したfile_operationsのopen関数.だからevdevに入ります.c中:
855 static const struct file_operations evdev_fops = {
856 .owner = THIS_MODULE,
857 .read = evdev_read,
858 .write = evdev_write,
859 .poll = evdev_poll,
860 .open = evdev_open,
861 .release = evdev_release,
862 .unlocked_ioctl = evdev_ioctl,
863 #ifdef CONFIG_COMPAT
864 .compat_ioctl = evdev_ioctl_compat,
865 #endif
866 .fasync = evdev_fasync,
867 .flush = evdev_flush,
868 .llseek = no_llseek,
869 }; 283 static int evdev_open(struct inode *inode, struct file *file)
284 {
285 struct evdev *evdev;
286 struct evdev_client *client;
287 int i = iminor(inode) - EVDEV_MINOR_BASE;
288 unsigned int bufsize;
289 int error;
290
291 if (i >= EVDEV_MINORS)
292 return -ENODEV;
293
294 error = mutex_lock_interruptible(&evdev_table_mutex);
295 if (error)
296 return error;
297 evdev = evdev_table[i];
298 if (evdev)
299 get_device(&evdev->dev);
300 mutex_unlock(&evdev_table_mutex);
301
302 if (!evdev)
303 return -ENODEV;
304
305 bufsize = evdev_compute_buffer_size(evdev->handle.dev);
306
307 client = kzalloc(sizeof(struct evdev_client) +
308 bufsize * sizeof(struct input_event),
309 GFP_KERNEL);
310 if (!client) {
311 error = -ENOMEM;
312 goto err_put_evdev;
313 }
314
315 client->bufsize = bufsize;
316 spin_lock_init(&client->buffer_lock);
317 snprintf(client->name, sizeof(client->name), "%s-%d",
318 dev_name(&evdev->dev), task_tgid_vnr(current));
319 wake_lock_init(&client->wake_lock, WAKE_LOCK_SUSPEND, client->name);
320 client->evdev = evdev;
321 evdev_attach_client(evdev, client);
322
323 error = evdev_open_device(evdev);
324 if (error)
325 goto err_free_client;
326
327 file->private_data = client;
328 nonseekable_open(inode, file);
329
330 return 0;
331
332 err_free_client:
333 evdev_detach_client(evdev, client);
334 wake_lock_destroy(&client->wake_lock);
335 kfree(client);
336 err_put_evdev:
337 put_device(&evdev->dev);
338 return error;
339 } 191 static void evdev_attach_client(struct evdev *evdev,
192 struct evdev_client *client)
193 {
194 spin_lock(&evdev->client_lock);
195 list_add_tail_rcu(&client->node, &evdev->client_list);
196 spin_unlock(&evdev->client_lock);
197 }297行、evdev_tableは前のconnect関数で分析しましたevdev_install_chrdev関数に保存されているここではminorの値に基づいて対応するevdevを取り出し、evdevのhanleに基づいて対応するinput_を見つけることができます.dev.307行は、報告されたデータを保存するメカニズムを作成し、その後分析され、321行evdev_attach_クライアントとは、クライアントをクライアントに追加することです.Listチェーンテーブルでは、323行でopenの処理を行い、open操作が完了します.
次にユーザ空間はread,poll,ioctlなどの操作を呼び出して過去のイベントに来て、androidが最もよく使うpoll+readメソッドを見て、最終的にevdevを呼び出します.cのfile_operationsでpoll:
433 static unsigned int evdev_poll(struct file *file, poll_table *wait)
434 {
435 struct evdev_client *client = file->private_data;
436 struct evdev *evdev = client->evdev;
437 unsigned int mask;
438
439 poll_wait(file, &evdev->wait, wait);
440
441 mask = evdev->exist ? POLLOUT | POLLWRNORM : POLLHUP | POLLERR;
442 if (client->packet_head != client->tail)
443 mask |= POLLIN | POLLRDNORM;
444
445 return mask;
446 }439行に示すように、poll操作はここでブロックされ、最下位のレポート・イベントの起動を待つ.次に、最下位のイベントの報告を見てみましょう.前のdrivers/input/keyboard/imapx 800_です.gpio.c中:
input_event(ptr->input, EV_KEY, ptr->code, 0);
input_sync(ptr->input);
詳細なオーバーレイヤはここでは分析されず、handlerのeventメソッドが呼び出されます.
95 static void evdev_event(struct input_handle *handle，
96 unsigned int type, unsigned int code, int value)
97 {
98 struct evdev *evdev = handle->private;
99 struct evdev_client *client;
100 struct input_event event;
101 struct timespec ts;
102
103 ktime_get_ts(&ts);
104 event.time.tv_sec = ts.tv_sec;
105 event.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
106 event.type = type;
107 event.code = code;
108 event.value = value;
109
110 rcu_read_lock();
111
112 client = rcu_dereference(evdev->grab);
113 if (client)
114 evdev_pass_event(client, &event);
115 else
116 list_for_each_entry_rcu(client, &evdev->client_list, node)
117 evdev_pass_event(client, &event);
118
119 rcu_read_unlock();
120
121 if (type == EV_SYN && code == SYN_REPORT)
122 wake_up_interruptible(&evdev->wait);
123 }104～108行対input_event構造体は、最終的にデータを報告する構造体、114行、最終的にkillを呼び出す値を付与する.fasync(&client->fasync,SIGIO,POLL_IN)は異ユーザ空間を起動異ユーザ空間を起動するステップ読み取りイベントを待つプロセスを使用し、これはアクティブにユーザ空間を起動する方法であり、122行は、前ユーザ空間pollのブロックを起動するので、前のpollがブロックしている場所に戻って、poll_waitはすでに起動され、ユーザー空間はデータが報告されたことを知っていて、それからreadを呼び出してデータを読み出して、このようにfile_を呼び出しましたoperationsのevdev_read:
397 static ssize_t evdev_read(struct file *file, char __user *buffer,
398 size_t count, loff_t *ppos)
399 {
400 struct evdev_client *client = file->private_data;
401 struct evdev *evdev = client->evdev;
402 struct input_event event;
403 int retval;
404
405 if (count < input_event_size())
406 return -EINVAL;
407
408 if (!(file->f_flags & O_NONBLOCK)) {
409 retval = wait_event_interruptible(evdev->wait,
410 client->packet_head != client->tail || !evdev->exist);
411 if (retval)
412 return retval;
413 }
414
415 if (!evdev->exist)
416 return -ENODEV;
417
418 while (retval + input_event_size() <= count &&
419 evdev_fetch_next_event(client, &event)) {
420
421 if (input_event_to_user(buffer + retval, &event))
422 return -EFAULT;
423
424 retval += input_event_size();
425 }
426
427 if (retval == 0 && file->f_flags & O_NONBLOCK)
428 retval = -EAGAIN;
429 return retval;
430 }