| 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
| ||
|
Message-ID: <20140831101358.GB19853@htj.dyndns.org> Date: Sun, 31 Aug 2014 06:13:58 -0400 From: Tejun Heo <tj@...nel.org> To: "Luis R. Rodriguez" <mcgrof@...not-panic.com> Cc: gregkh@...uxfoundation.org, dmitry.torokhov@...il.com, falcon@...zu.com, tiwai@...e.de, arjan@...ux.intel.com, 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 Hello, Luis. I haven't followed the previous discussions so please let me know if this has been discussed before. It looks like you're trying to extend the async mechanism and applying them to init functions themselves. That sounds kinda weird to me. Isn't the root cause of the problem doing device probings along with driver initilaization on module load? Wouldn't it be more logical to simply make bus_add_driver() -> driver_attach() invocation asynchronous? There's no reason to make them parallel either. We can use an ordered queue for it so that we don't lose the probing order we used to have. Making things go parallel is the responsibility of each probing function after all and there isn't much to gain by making attach calls go parallel. Thanks. -- tejun -- 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/
Powered by blists - more mailing lists