Date: Wed, 3 Apr 1996 13:13:32 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Cc: terry@lambert.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: It isn't easy being "green"... Message-ID: <199604032013.NAA19795@phaeton.artisoft.com> In-Reply-To: <9603038285.AA828559516@ccgate.infoworld.com> from "Brett Glass" at Apr 3, 96 12:11:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Uh... because it's impossible to offer the spindown disabling safely > > in a drive/controller independent fashion? > > Why is this impossible? If the flag is set and the drive is not positively > identified as one we know how to deal with, the code can simply print a > message and continue. That's *not* "a drive/controller independent fashion". That's a "massive rogues list and embedded p-code for each supported drive fashion". If the "disable green mode" is settable at "boot -c", you can only install drives in the "rogues list". Green drives not in the list still can't be installed. On the other hand, if the controller driver "gracefully handles spindown", you can install all green drives, period, regardless of whether or not they are "known rogues". Which is to say, "disable green mode" is a nice post-install option, but it's not the way to generically fix the install. And since the usefulness of disabling the mode is limited to people with a burning need to run down the batteries in their laptops as quickly as possible, it seems to me that it has a limited audience (or an audience of laptop owners running on other-than-battery or people with "green desktop machines" that they really didn't want to be green. I'd actually like to see this rolled into the standard APM code being written by Nate and the Nomads (good name for a band 8-)). > > But you can reliably recover from a spin-down, if your disk driver > > has been written correctly. > > Perhaps. But it may still be desirable (in fact, necessary!) to disable > spindowns to get adequate performance. Therefore, FreeBSD should offer this > option. Agree. I think it is a post-install tuning option. > > So the generic soloution must be to recover from spindown, not to > > disable it. > > I half agree. Recovery from spindown is important for laptops and other > situations where one might like to conserve power. Turning off spindown is > important to allow reasonable performance on the desktop and in multi-user > situations -- and is ABSOLUTELY NECESSARY until graceful recovery from > spindown is possible. BOTH should be implemented. I'd be glad to do work > on recognition code that makes the latter safe and adaptable to many brands > of drives. I think graceful recovery from spindown is absolutely necessary, and ability to disable features that you have to go out of your way to find in a computer (so presumably you wanted them to work instead of being disabled) ought to be a controllable option. In the name of the controllable option, the code ought to go ahead. But it ought to be a user space utility where most of the code lives... I think the primary use is for employees of companies trying to get the EPA tax incentive for energy conservation by putting unreasonably performant green machines on their employees desks. 8-). As a workaround to making the drivers robust (which is something I strongly think should *not* be worked around to incent a real fix), you might be able to convince Jordan to call the utility as part of the install. This should be sufficient to kludge around the bad driver code, which is the problem that originally bit you in the first place, without making it "standard practice". After you install (or maybe as part of the install, checking the return code of the utility), you could add the command to the rc.local. I'd hate for this to happen without making someone actively edit the script, since I don't think it should be the default. I think it's in the same category as the TCP/IP extensions (which default to on, even though they cause a lot of support problems that wouldn't be there if they didn't). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604032013.NAA19795>