Date: Tue, 2 Apr 1996 16:11:32 +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: <199604020641.QAA12379@genesis.atrad.adelaide.edu.au> In-Reply-To: <9603018284.AA828422418@ccgate.infoworld.com> from "Brett Glass" at Apr 1, 96 09:54:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass stands accused of saying: > > > Don't do it this way, particularly since you are adding a command > > to activate a vendor-specific function. > > > You should create a rogues table, and define your Seagate fix as a > > 'rogue feature', triggered by the drive id in wdattach(). > > If it were done this way, timeouts would always be turned off even when > power savings were desired. It's better to keep it optional. Therefore, > two configuration flags -- one for the master and one for the slave -- > would still be a good idea, even in the presence of a "rogues" table. Timeouts should default to off, in order to deal with problems like yours. 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. "Works suboptimally" is a better default case than "crashes strangely". 8) > Kernel configuration flags, on the other hand, are great because > they are available right away. They can be set using the configuration > editor at boot time, so that inactivity timeouts are disabled as soon as > the OS starts up. The flagspace is too small. There are a few ideas brewing (kernel "environment variables", for example) that would help get around this, but nothing that's anywhere near showtime. > immediately (or not!) as the driver starts up. If a drive's NO_IDLE flag is > turned on, wdgetctrlr() (which is called by wdattach()) can check a table, > as you described. Better still, it can invoke a cascade of > detection/configuration routines, each designed to handle some makes and > models. The first routine that recognizes the drive configures it and exits > the chain. If execution "falls out the bottom," or a configuration command 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. If the ID strings are formatted in a 'civilised' fashion, it should be possible to select on manufacturer, model or revision by only comparing the length of ID supplied in the table. > off. (The big advantage of this approach over a table is that the routines > can do specialized parsing on drive IDs, handling groups of model numbers > and suffixes elegantly.) ... but requiring the wheel to be reinvented for every new quirk, bloating the driver and making the code even harder to understand 8) > Sound like a plan? Throw it around a few more times, let some of the _real_ pickers think about it, and do it! > --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?199604020641.QAA12379>