From owner-freebsd-hardware Wed Apr 3 07:43:54 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA02990 for hardware-outgoing; Wed, 3 Apr 1996 07:43:54 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA02982 Wed, 3 Apr 1996 07:43:51 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u4V6m-000wujC; Wed, 3 Apr 96 08:08 PST Received: from cc:Mail by ccgate.infoworld.com id AA828546177; Tue, 02 Apr 96 15:43:16 PST Date: Tue, 02 Apr 96 15:43:16 PST From: "Brett Glass" Message-Id: <9603038285.AA828546177@ccgate.infoworld.com> To: Terry Lambert Cc: terry@lambert.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Actually "fixing" the problem requires making the driver aware of drive > spin downs and making it deal with it transparently instead of screwing > up by passing an error to higher level code. This is one way to solve the problem. However, disabling spindowns is also a viable solution. Why not offer both? > Disabling the spindown is not what I'd call "making the code 'green > aware'"... No, but it is both a performance enhancement and a way to ensure that things work. That's why I'd propose using config flags -- so that the system will be able to perform adequately during installation and immediately thereafter -- AND a utility that could change the setting later on. Both could be based on some of the kernel hacking I've already done here. --Brett