Date: Wed, 03 Apr 96 09:29:25 PST From: "Brett Glass" <Brett_Glass@ccgate.infoworld.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, hardware@freebsd.org Subject: Re: Some solutions to disk problems.... I think. Message-ID: <9603038285.AA828550952@ccgate.infoworld.com>
next in thread | raw e-mail | index | archive | help
>> 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. > A simple wildcard matching routine would handle this sort of thing. The patterns would require some complex matching. > 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. > I guess I'm pointing at prior art (all of the SCSI rogue detection code > I've ever seen in operating systems), and saying "this works. They're > probably smarter than either me or you, so let's do it the same way" 8) 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. --Brett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9603038285.AA828550952>