From owner-freebsd-hackers Thu Apr 6 18:38:39 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA17631 for hackers-outgoing; Thu, 6 Apr 1995 18:38:39 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id SAA17622 for ; Thu, 6 Apr 1995 18:38:35 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA17024 (5.67a/IDA-1.5); Thu, 6 Apr 1995 20:09:43 -0500 Received: by bonkers.taronga.com (smail2.5p) id AA12764; 6 Apr 95 20:02:16 CDT (Thu) Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.6) id UAA12761; Thu, 6 Apr 1995 20:02:16 -0500 From: Peter da Silva Message-Id: <199504070102.UAA12761@bonkers.taronga.com> Subject: Re: Suggestion on slow probing devices To: uhclem@nemesis.lonestar.org (Frank Durda IV) Date: Thu, 6 Apr 1995 20:02:15 -0500 (CDT) Cc: hackers@FreeBSD.org In-Reply-To: from "Frank Durda IV" at Apr 5, 95 08:11:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 783 Sender: hackers-owner@FreeBSD.org Precedence: bulk > If you say, "OK, I'll start one slow thing, then bail out and let everyone > else initialize" (including the others who also quickly bail out), then after > a bit the ball comes back to you. Now what? If you start something else > slow and then say "come back later", there will be less and less other > drivers needing initialization to spend the intervening time on. True. If you're slow enough there's no big gain. The point is that the mechanism (return a status that says poll me again) is no more complex than (poll in two phases), and in one specific case it's going to be a big win: when you have two or more populated SCSI busses. Right now you have a delay with *each* device on *each* bus. If you used this mechanism it'd just naturally probe all busses in parallel.