linux-kernel - [RFC PATCH 0/5] driver core: driver probe asynchronously

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun,  9 Sep 2012 07:25:15 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Takashi Iwai <tiwai@...e.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linux-kernel@...r.kernel.org
Subject: [RFC PATCH 0/5] driver core: driver probe asynchronously

Hi,

This patchset implements asynchronous driver probe for driver_register,
and try to address the below problems about driver init during
kernel boot:
	- help to solve some dependency problem during kernel boot
	(such as, request_firmware is called inside probe when driver
	is built in kernel[1])

The idea behind the patch is very simple:

	- seperate driver probe from driver_register and run this part
	in one standalone kernel thread context

	- so driver_register will become two parts: register the driver
	on the bus, and trigger to schedule a kernel thread to do the
	driver probe if autoprobe is set

Fortunately, my OMAP4 based Pandaboard boots fine with the patchset, and
looks it may work well.

More or less, some problems might be triggered by these patchset, but
it should be helpful and not a big deal:
	- the dependency problem may be found, and it either exposes
	the driver's probelm or help to improve the asynchronous probe
	approach

	- can use driver_register_sync to work around it

In summary, there are at least two advantages about asynchronous driver
probe:
	- speedup kernel boot when many drivers are built in kernel
	- make driver's probe() not need to consider running something
	asynchronously(such as, scsi scan, request_firmware_no_wait, ...),
	so easier to write drivers

It should a very simple way to help to solve the problem[1], without
any changes on current drivers which call request_firmware() in its
probe(). BTW, the patchset doesn't solve the problem completely, and
still some work is needed.


[1], http://marc.info/?t=134676416100002&r=1&w=2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/