From owner-freebsd-hardware Wed Apr 3 21:41:22 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA27814 for hardware-outgoing; Wed, 3 Apr 1996 21:41:22 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA27674 for ; Wed, 3 Apr 1996 21:40:41 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id PAA25320; Thu, 4 Apr 1996 15:32:38 +0930 From: Michael Smith Message-Id: <199604040602.PAA25320@genesis.atrad.adelaide.edu.au> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Thu, 4 Apr 1996 15:32:37 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org In-Reply-To: <9603038285.AA828550952@ccgate.infoworld.com> from "Brett Glass" at Apr 3, 96 09:29:25 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > >> In this case, it's easy to enlarge. Just expose per-drive flags as well > >> as per-controller flags. > > > That's not possible; the drives aren't visible until after they're > > probed, > > Controllers are visible before they're probed. Why not drives? We know that > an IDE interface can have at most two. *sigh* The whole point is that _nothing_ other than the 'wd' driver should know this; it needs (and for the most part has) no special-case code. Adding such code would be bogus in the extreme. > > A simple wildcard matching routine would handle this sort of thing. > > The patterns would require some complex matching. You want to be able to match a vendor string and a model number. If the textual content changes, you duplicate the entry in the table. It's nice and easy, and right where you can see it. > > The excess of functions duplicating essentially the same functionality > > makes it very difficult to see, at a glance, what is being searched for. > > Different things will be searched for in different cases. It's easy to > break this out into functions that search for the right thing in each case. Huh? You can "search for" the contents of the ID string. > I've seen the SCSI rogue detection code. The difference is that SCSI IDs > are much more constrained by standards than IDE/ATA IDs. And here, we're > not really talking about "rogues;" we need to know the right thing to do > for EVERY drive we handle. This makes the table much bigger than if it only > handles exceptional cases. No, egregious monsterism aside, the majority of drives still follow the spec. All you want is a list of drives that behave outside the envelope that's required for conformance with the driver. This is not 'all drives', as is demonstrated by the lack of such a table to date. > --Brett -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[