From owner-freebsd-hackers Wed Apr 5 23:38:54 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA11895 for hackers-outgoing; Wed, 5 Apr 1995 23:38:54 -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 XAA11886 for ; Wed, 5 Apr 1995 23:38:46 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA04513 (5.67a/IDA-1.5); Thu, 6 Apr 1995 00:37:05 -0500 Received: by bonkers.taronga.com (smail2.5p) id AA16025; 5 Apr 95 19:49:00 CDT (Wed) Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.6) id TAA16022; Wed, 5 Apr 1995 19:49:00 -0500 From: Peter da Silva Message-Id: <199504060049.TAA16022@bonkers.taronga.com> Subject: Re: Suggestion on slow probing devices To: bde@zeta.org.au (Bruce Evans) Date: Wed, 5 Apr 1995 19:49:00 -0500 (CDT) Cc: phk@ref.tfs.com, freebsd-hackers@freefall.cdrom.com, uhclem@nemesis.lonestar.org In-Reply-To: <199504051738.DAA26590@godzilla.zeta.org.au> from "Bruce Evans" at Apr 6, 95 03:38:48 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 652 Sender: hackers-owner@FreeBSD.org Precedence: bulk > > > The solution was to create two probing passes. The system would > > > effectively call each devices' probe routine twice. > > How about generalizing it? If there's a big delay, have the probe return a > > flag saying "more work to do, call me again after you've asked everyone > > else". That way you could handle multi-stage delays, like with SCSI. > I'd say the right thing to do would be to get the timer flying and make > a "HW-probe-attach" process... That would be even niftier, though a lot more complex and tricky. Do you think it'd save much (that is, are the delays long enough that you'll still have slack in a multi-stage probe)?