linux-kernel - Re: [RFC v1 0/3] driver-core: add asynch module loading support

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 31 Aug 2014 07:44:02 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	gregkh@...uxfoundation.org, dmitry.torokhov@...il.com,
	falcon@...zu.com, tiwai@...e.de, tj@...nel.org
CC:	linux-kernel@...r.kernel.org, oleg@...hat.com,
	akpm@...ux-foundation.org, penguin-kernel@...ove.sakura.ne.jp,
	joseph.salisbury@...onical.com, bpoirier@...e.de,
	"Luis R. Rodriguez" <mcgrof@...e.com>
Subject: Re: [RFC v1 0/3] driver-core: add asynch module loading support

On 8/31/2014 2:03 AM, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@...e.com>
>
> While reviewing Wu Zhangjin's solution to async probe [0] and his
> ideas on creating async groups I decided to try following the init
> levels on the kernel to try to help with synchronization at least
> on some level. This borrows ideas discussed with the kthread_create()
> solution [1] and also simplifies the idea of how we should be grouping
> async calls between drivers.
>
> A few things worth mentioning. I decided to go down a generic solution as
> if we ever wanted to bring asynchrnonization behaviour below modules
> this would allow folks to start testing this without much effort. It
> allows asynchronous calls to upkeep the order already set in place
> for built-in code. If one wanted to eventually venture down below
> that path we'd need to add respective exit calls for each level, as
> right now we just assume that every level should use module_exit().
> SmPL grammer could be used to easily tidy this up, for example on
> the subsys_init():

before we added the current async approach the approach of async init calls was tried
At the time, Linus hated it and he was right, it was not the right thing.

What is different this time to make this the right thing to do ?


--
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/