From owner-freebsd-hackers Wed Apr 5 08:37:06 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA22864 for hackers-outgoing; Wed, 5 Apr 1995 08:37:06 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA22858 for ; Wed, 5 Apr 1995 08:37:05 -0700 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id IAA08584; Wed, 5 Apr 1995 08:36:49 -0700 From: Poul-Henning Kamp Message-Id: <199504051536.IAA08584@ref.tfs.com> Subject: Re: Suggestion on slow probing devices To: peter@bonkers.taronga.com (Peter da Silva) Date: Wed, 5 Apr 1995 08:36:48 -0700 (PDT) Cc: uhclem@nemesis.lonestar.org, freebsd-hackers@freefall.cdrom.com In-Reply-To: <199504051143.GAA03868@bonkers.taronga.com> from "Peter da Silva" at Apr 5, 95 06:43:11 am Content-Type: text Content-Length: 638 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... -- Poul-Henning Kamp -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant'