From owner-freebsd-hardware Fri Apr 5 19:02:51 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA00589 for hardware-outgoing; Fri, 5 Apr 1996 19:02:51 -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 TAA00584 for ; Fri, 5 Apr 1996 19:02:47 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id MAA02845; Sat, 6 Apr 1996 12:56:29 +0930 From: Michael Smith Message-Id: <199604060326.MAA02845@genesis.atrad.adelaide.edu.au> Subject: Re: Some solutions to disk problems.... I think. To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Sat, 6 Apr 1996 12:56:28 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org In-Reply-To: <9603048286.AA828638254@ccgate.infoworld.com> from "Brett Glass" at Apr 4, 96 09:56:08 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: > > > Here's a suggestion. Write a function that performs simple string > > matching using a table of ten IDs. Write ten functions which each parse > > for these ID's. Compare the size of the two. Repeat the process for > > twenty, and so on. > > I hope you are jesting! Only the most abysmal programmer would have to > write ten functions to replace ten table entries. If there are ten different quirks, then there are ten different functions to manage those quirks. I think what you're failing to see is that with a table-based approach, the table grows linearly with the number of drives recognised, and the function space grows with the number of quirks managed. Lookup time remains short and linear, and there is a clear, central reference to the drives and quirks recognised. With your approach, every single 'quirk management' function has to be called, and the ID string from the drive is parsed again, and again, and again. This is _inefficient_, difficult to follow, difficult to understand, and because you reinvent the parsing wheel again and again and again, you bloat even faster. > Seagate alone has several HUNDRED model numbers. In my hard disk guide, > they go on for PAGES in fine print. And that's just one brand. Recognizing > substrings of different lengths, and knowing when to look for suffixes as > well as the corresponding CDC and Conner model numbers, will be key to > identifying drives efficiently. I've never disputed this. I think you're just looking at doing it from the wrong direction. (Bear in mind that most of the drives that you're looking at there require _no_ special handling...) > --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 [[