Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Apr 1996 12:56:28 +0930 (CST)
From:      Michael Smith <msmith@atrad.adelaide.edu.au>
To:        Brett_Glass@ccgate.infoworld.com (Brett Glass)
Cc:        msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org
Subject:   Re: Some solutions to disk problems.... I think.
Message-ID:  <199604060326.MAA02845@genesis.atrad.adelaide.edu.au>
In-Reply-To: <9603048286.AA828638254@ccgate.infoworld.com> from "Brett Glass" at Apr 4, 96 09:56:08 am

next in thread | previous in thread | raw e-mail | index | archive | help
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  [[



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604060326.MAA02845>