From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 08:15:43 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3F4316A401; Mon, 26 Jun 2006 08:15:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D27343D9B; Mon, 26 Jun 2006 08:15:43 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D2B8146BC1; Mon, 26 Jun 2006 04:15:42 -0400 (EDT) Date: Mon, 26 Jun 2006 09:15:42 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pawel Jakub Dawidek In-Reply-To: <20060626080038.GA12511@garage.freebsd.pl> Message-ID: <20060626090937.U24406@fledge.watson.org> References: <20060626031636.GK82074@funkthat.com> <33398.1151304697@critter.freebsd.dk> <20060626080038.GA12511@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Poul-Henning Kamp , John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 08:15:43 -0000 On Mon, 26 Jun 2006, Pawel Jakub Dawidek wrote: > On Mon, Jun 26, 2006 at 06:51:37AM +0000, Poul-Henning Kamp wrote: >> In message <20060626031636.GK82074@funkthat.com>, John-Mark Gurney writes: >> >>> Can't we expand the disk api? add a const char *d_serial to the struct >>> disk, and have the disk api automaticly propegate the serial number up >>> to the geom layer? >> >> This is more or less what Pawel asked me for, and I am not at all >> convinced that is how we want to do it. > > Actually I proposed the opposite: remove some d_* fields and make them > available via discussed mechanism. Yes -- one of the problems/benefits of the disk(9) API is that it's a very narrow API. I'd like to see an attribute API pushed into disk(9) so that GEOM modules can query additional disk properties in much the same way they can query GEOM attributes. However, I think that we should not move existing mandatory fields out if they really are mandatory -- right now the API guarantees that certain values will always be available, and will not change. By re-exposing them via an attribute interface, we allow for the possibility of them being unavailable or changing. GEOM univerally provides similar guarantees, such as sectorsize not changing. Media size is a slightly more dubious one, of course, and probably should become variable. Robert N M Watson Computer Laboratory University of Cambridge