| 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: <20070509153813.52a7c397@gondolin.boeblingen.de.ibm.com> Date: Wed, 9 May 2007 15:38:13 +0200 From: Cornelia Huck <cornelia.huck@...ibm.com> To: Greg KH <greg@...ah.com> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Adrian Bunk <bunk@...sta.de>, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE) On Wed, 9 May 2007 02:53:02 -0700, Greg KH <greg@...ah.com> wrote: > > 2. Sheer volume of devices on a bus. Even if the indivdual probing > > doesn't take long, having all devices probed one after the other may > > take a lot of time. Putting the actual probe on a thread makes it > > possible to run several probes in parallel, thereby cutting probing > > time. > > Again, not for PCI, right? It seems that everyone agrees now that moving PCI over to a new probing model without individual driver support was a bad idea. So generic multithreaded probing is dead. > If you want to implement this for your bus type, fine, I have no > objection to that at all, but not for PCI, it's just not worth it. Infrastructure for async probing might not be such a bad idea, though. (Aren't there some huge PCI-based machines?) However, I don't really care whether PCI or SCSI or $HUGE_BUS use it, but serial synchronous probing on a bus looks like a killer on most large systems. - 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