From owner-svn-src-all@FreeBSD.ORG Wed Dec 8 06:03:44 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 116BC106564A; Wed, 8 Dec 2010 06:03:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD748FC12; Wed, 8 Dec 2010 06:03:43 +0000 (UTC) Received: from c122-106-172-0.carlnfd1.nsw.optusnet.com.au (c122-106-172-0.carlnfd1.nsw.optusnet.com.au [122.106.172.0]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oB863X5K019020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Dec 2010 17:03:34 +1100 Date: Wed, 8 Dec 2010 17:03:32 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Cran In-Reply-To: <20101207230624.7b7a83d3@core.draftnet> Message-ID: <20101208164726.T1583@besplex.bde.org> References: <201012072046.oB7KkB4L079555@svn.freebsd.org> <4CFEAD09.30904@freebsd.org> <20101207230624.7b7a83d3@core.draftnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Andriy Gapon Subject: Re: svn commit: r216269 - head/sys/geom/part X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 06:03:44 -0000 On Tue, 7 Dec 2010, Bruce Cran wrote: > On Tue, 07 Dec 2010 23:54:17 +0200 > Andriy Gapon wrote: > >> You repeated that statement, so I am picking on you :-) >> Can someone show me how/where exactly modern drives fakes CHS >> geometry? Let me specifically ask that question about modern (S)ATA >> drives directly connected to a system (controller). >> My impression is at least since ATA-7 there is no mentioning of >> anything CHS-related in the specification. The fact that we keep >> reading and interpreting some historically defined bytes that are now >> marked as unused/reserved doesn't mean that those bytes actually mean >> anything. > > You're right: I last looked at the IDENTIFY data about 7 years ago when > those fields were defined; now they're marked as "obsolete". I guess > the fields are still defined to keep old tools happy. Both atacontrol > and camcontrol are still reading the IDENTIFY data and outputting > the CHS fields even on ATA-8 drives, which I guess they shouldn't be. Utilities for reporting capabilities must report capabilities if they are supported. Whether unsupported fields should be reported as integer 0's or in a special format (e.g., not printing anything for unsupported sub-fields) is another question. atacontrol is a bit too simple and inconsistent. It prints CHS values unconditionally. Then it prints "CFA supported" if CFA is supported, else nothing. Then it inconsistently prints "LBA supported " if LBA is supported, else "LBA not supported ". Then it prints the number of sectors supported by LBA, but under a different condition. Then it prints many more things like it prints LBA, using "supported/not supported" or, again inconsistently, "yes/no" instead of "supported"/nothing. Bruce