init: no need to wait device probe
PATCH 1/1 init: no need to wait device probe
From: Zhang Ning <[email protected]>
there are 2 reasons for no need to wait device probe
reason 1:
mount root device is very late in kernel initial stage. all initcalls are finished. that means most of probe functions are returned.
and deferred probe are also finished by late_initcall. only async probe driver are possible in probing.
no block devices, device-mapper or nfs are use async probe. so no need to wait device probe.
reason 2:
let's check dd.c, probe_count is increased and decreased only in really_probe, and when really_probe returns, probe_count always be 0.
when someone really wants to wait device-B probe. but code looks like:
thread-1: thread-2:
probe device-A; wait_for_device_probe();
msleep(30);
probe device-B
when device-A probe finishes, thread-2 will be wakeup, but device-B is not probed.
wait_for_device_probe can't make sure the device you want is probed.
based on above 2 reasons, no need to wait for device probe.
--- init/do_mounts.c | 9 --------- init/do_mounts_md.c | 2 -- 2 files changed, 11 deletions(-)
init/do_mounts.c +0 -9
@@ -555,15 +555,6 @@ void __init prepare_namespace(void)ssleep (root_delay); } -/* -* wait for the known devices to complete their probing -* -* Note: this is a potential source of long boot delays. -* For example, it is not atypical to wait 5 seconds here -* for the touchpad of a laptop to initialize. -*/ -wait_for_device_probe (); -md_run_setup ();if (saved_root_name[0 ]) {
init/do_mounts_md.c +0 -2
@@ -292,8 +292,6 @@ static void __init autodetect_raid(void)printk (KERN_INFO "md: Waiting for all devices to be available before autodetect\n" );printk (KERN_INFO "md: If you don't use raid, use raid=noautodetect\n" ); -wait_for_device_probe (); - fd =sys_open ("/dev/md0" ,0 ,0 );if (fd >=0 ) {sys_ioctl (fd,RAID_AUTORUN , raid_autopart);
Signature · 1 line
2.14.2
Hi,
Quoted 1 line · On 03/15/2018 12:20 AM, [email protected] wrote:
From: Zhang Ning <[email protected]>
meta comment (i.e., not about the merits of the patch itself):
You'll need to send the patch to someone if you want it to be merged. Maintainers don't mine mailing lists for patches to apply.
Quoted 73 lines
there are 2 reasons for no need to wait device probe
reason 1:
mount root device is very late in kernel initial stage. all initcalls are finished. that means most of probe functions are returned.and deferred probe are also finished by
late_initcall. only async probe driver are possible in probing.no block devices, device-mapper or nfs are use async probe. so no need to wait device probe.
reason 2:
let's checkdd.c,probe_countis increased and decreased only inreally_probe, and whenreally_probereturns,probe_countalways be 0.when someone really wants to wait device-B probe. but code looks like:
thread-1: thread-2:
probe device-A;wait_for_device_probe();
msleep(30);
probe device-Bwhen device-A probe finishes, thread-2 will be wakeup, but device-B is not probed.
wait_for_device_probecan't make sure the device you want is probed.based on above 2 reasons, no need to wait for device probe.
Signed-off-by Zhang Ning <[email protected]>--- init/do_mounts.c | 9 --------- init/do_mounts_md.c | 2 -- 2 files changed, 11 deletions(-)init/do_mounts.c +0
-9@@ -555,15 +555,6 @@ void __init prepare_namespace(void)ssleep (root_delay); } -/* -* wait for the known devices to complete their probing -* -* Note: this is a potential source of long boot delays. -* For example, it is not atypical to wait 5 seconds here -* for the touchpad of a laptop to initialize. -*/ -wait_for_device_probe (); -md_run_setup ();if (saved_root_name[0 ]) {init/do_mounts_md.c +0
-2@@ -292,8 +292,6 @@ static void __init autodetect_raid(void)printk (KERN_INFO "md: Waiting for all devices to be available before autodetect\n" );printk (KERN_INFO "md: If you don't use raid, use raid=noautodetect\n" ); -wait_for_device_probe (); - fd =sys_open ("/dev/md0" ,0 ,0 );if (fd >=0 ) {sys_ioctl (fd,RAID_AUTORUN , raid_autopart);
Signature · 1 line
~Randy
Quoted 1 line · 在 2018-03-17六的 12:17 -0700,Randy Dunlap写道:
Maintainers don't mine mailing lists for patches to apply.
thank you very much, I will resend my patch.
BR.
Ning.