Date: Tue, 02 Apr 96 08:30:30 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: <9603028284.AA828461240@ccgate.infoworld.com>
next in thread | raw e-mail | index | archive | help
> Timeouts should default to off, in order to deal with problems like > yours. I'm not so sure. Pity the poor laptop owner whose drive spins up relatively quickly (so that turning off the timeout isn't absolutely necessary). He installs FreeBSD, and suddenly finds his batteries completely discharged! The mailing lists receive dozens of complaints, and FreeBSD becomes known as a notebook power hog. > The rogues table would also be able to indicate to ioctl code > that wanted to reenable power-saving modes that the disk required special > handling. In other words, you'd want to create a "power saving" ioctl? > The flagspace is too small. In this case, it's easy to enlarge. Just expose per-drive flags as well as per-controller flags. > That's not so crash hot. Use a table with a list of drive ID responses > and flags which define quirks; it's not just at attach time that oddities > may have to be worked around. A table would not cover all the contingencies. Each manufacturer has its own way of creating model numbers for products. Some put letters at the beginning; some at the end. Some have, over time, switched the letters from the end to the beginning or vice versa. (Maxtor, for example, moved the letters from the end to the beginning, then added more at the end again.) Some have hyphens in the model numbers (or have added or removed them over time). Some have dozens of models that act similarly; there's no need to bloat the table by adding every one. Some have even changed their numbering systems during mergers and acquisitions. A cascade of routines that both recognize ID strings and act on the relevant devices is, in my experience, the most efficient and elegant solution. If one tries to implement a table, one winds up having to include recognition code anyway; the table becomes a waste of space. > ... but requiring the wheel to be reinvented for every new quirk, > bloating the driver and making the code even harder to understand 8) If the code is organized in a sensible manner, and has even a few comments saying what it's doing, it is easier to understand. As for bloating: as explained above, a table would likely bloat the code more than a simple routine. The code to issue the command is usually quite small; I did the Seagate in three lines (including just one function call). The recognition code *has* to be there if one is going to have accurate recognition. --Brett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9603028284.AA828461240>