From owner-freebsd-hackers  Wed Apr  3 11:26:24 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id LAA16907
          for hackers-outgoing; Wed, 3 Apr 1996 11:26:24 -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 LAA16867
          Wed, 3 Apr 1996 11:26:18 -0800 (PST)
Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp
	(Smail3.1.29.1 #12) id m0u4YaA-000wuRC; Wed, 3 Apr 96 11:51 PST
Received: from cc:Mail by ccgate.infoworld.com
	id AA828559516; Wed, 03 Apr 96 12:11:13 PST
Date: Wed, 03 Apr 96 12:11:13 PST
From: "Brett Glass" <Brett_Glass@ccgate.infoworld.com>
Message-Id: <9603038285.AA828559516@ccgate.infoworld.com>
To: Terry Lambert <terry@lambert.org>
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-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 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.

> The 0xFB for the Seagate is not the same as is used by all other "green"
> hard disks, if they even support it in the first place...

True. That's why the command should be issued only in the case where the
drive has been identified.

> That's the problem... it can't ensure this because you can't send the
> command reliably.

Why not? Again, the above approach would handle the odd cases.

> 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.

> 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.

--Brett