Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967017AbXEHSab (ORCPT ); Tue, 8 May 2007 14:30:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S966191AbXEHSab (ORCPT ); Tue, 8 May 2007 14:30:31 -0400 Received: from smtp1.linux-foundation.org ([65.172.181.25]:39862 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966035AbXEHSaa (ORCPT ); Tue, 8 May 2007 14:30:30 -0400 Date: Tue, 8 May 2007 11:30:03 -0700 (PDT) From: Linus Torvalds To: Cornelia Huck cc: Adrian Bunk , Greg K-H , linux-kernel Subject: Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE) In-Reply-To: <20070508183846.28a94797@gondolin.boeblingen.de.ibm.com> Message-ID: References: <20070508153713.344cc881@gondolin.boeblingen.de.ibm.com> <20070508141149.GJ4226@stusta.de> <20070508183846.28a94797@gondolin.boeblingen.de.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1901 Lines: 50 On Tue, 8 May 2007, Cornelia Huck wrote: > > > Threading at a driver level still does that (ie individual disks may be > > attached in some order that depends on how fast they are to respond), but > > in a much more controlled fashion, and only for drivers that explicitly > > say that they can do it. > > How is that better? You still must rely on udev for persistent device > names. It's better because then the *driver* can decide whether it supports threaded probing or not. The threaded PCI bus probing was totally and utterly broken exactly because many drivers were simply not willing or able to handle it. Also, quite frankly, when this came up I already posted a much better approach for allowing arbitrary threading. It was ignored, but maybe you want to take a look. See http://lkml.org/lkml/2006/10/27/185 for last time this came up. Any driver can decide to do execute_in_parallel(myprobe, myarguments); and that really *simple* thing allows synchronization points ("wait_for_parallel()") and arbitrary setting of the allowed parallelism. I really think that is a *much* better approach. It allows, for example, the driver to do certain things (like name allocations and any particularly *fast* parts of probing) synchronously, and then do slow things (like spinning up disks and actually reading the partition tables) asynchronously. Anyway, I will refuse to merge anything that does generic bus-level (unless the bus is something off-the-board like SCSI) parallelism, unless you can really show me how superior and stable it is. I seriously doubt you can. We tried it once, and it was a total disaster. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/