From owner-freebsd-arch Fri Oct 25 8:12:58 2002 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 55B3D37B401 for ; Fri, 25 Oct 2002 08:12:56 -0700 (PDT) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DDC243E75 for ; Fri, 25 Oct 2002 08:12:50 -0700 (PDT) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9PFCecF049792; Fri, 25 Oct 2002 16:12:41 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9PFCeH5072318; Fri, 25 Oct 2002 16:12:40 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9PFCenT072317; Fri, 25 Oct 2002 16:12:40 +0100 (BST) Date: Fri, 25 Oct 2002 16:12:40 +0100 (BST) From: Mark Valentine Message-Id: <200210251512.g9PFCenT072317@dotar.thuvia.org> In-Reply-To: <17783.1035552121@critter.freebsd.dk> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Poul-Henning Kamp Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_dis Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Poul-Henning Kamp > Date: Fri 25 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_dis [Recipient list trimmed, moved from cvs-all to -arch.] > In message <200210251307.g9PD7al6069458@dotar.thuvia.org>, Mark Valentine write > s: > >I guess we differ here in that I'm saying we *should* hide this implementation > >detail by default for consistency with other platforms, > > You're making quite an assumption here it seems: BSD disklabels may not > even be present on all platforms, and each partitioning scheme is free > to choose its own naming. Yes, I was assuming the presence of a BSD disklabel for the purposes of the discussion. I earlier made the point that if you don't have a BSD disklabel, the picture doesn't change substantially. The standard BSD device naming scheme can (and should) still be used. > GPT labels for instance seems to use "${disk}${unit}[sp]%d" This is an implementation detail. Certainly, if the native platform has its own partitioning scheme which is up to the task, there's no need to write a separate BSD disklabel to the disk. Whether or not you still present a disklabel API is a matter for consideration, but in any case the system should map the underlying structure onto the traditional scheme for POLA purposes. I see no reason not to *also* present an interface to the physical device structure (see separate posting on cvs-all), but the traditional scheme should be preserved, for example mapping da0a -> disk0p4. I certainly prefer no BSD disklabel to one hidden behind a representation of the native partitioning (the da0s4a stuff). If you make it allowable to have multiple BSD disklabels on a disk (for whatever reason), please don't obfuscate the common case to do it. In particular, the FreeBSD/i386 convention of using a _numbered_ "slice" is bogus; even if you consider the DOS partitioning scheme "native" (which it is not strictly speaking, since it's implemented entirely by DOS rather than the BIOS), it does not map directly onto the scheme DOS uses to identify partitions (by partition type then by its drive letter assignment algorithm). This is what causes /etc/fstab to become invalid if using hard-coded slice numbers after some non-FreeBSD tool re-arranges the order of the DOS partition table (which some tools indeed seem to be consider a valid thing to to; perhaps this is why QNX used a convention something like /dev/hd0t165). > And finally you overlook that we may have to forego both MBR and BSD > disklabels on any architecture where we want to use moderately large > storage devices (2^31 * 512 bytes, possibly twice that). What is a typical device naming scheme for such an architecture? > There simply isn't "any consistency with other platforms" to point to > here, if we disregard stuff from the antique hardware society. # uname -rms NetBSD 1.6 sparc # mount /dev/sd0a on / type ffs (local) /dev/sd0d on /var type ffs (local) /dev/sd0e on /usr type ffs (local) /dev/sd0g on /local type ffs (local) This is BSD present day reality; you have provided no justification why this shouldn't continue to work. > Now, this is a nice technicolor bikeshed we got here, but can we > get on with something of real importance, like, making a FreeBSD > 5.0-RELEASE ? Yup, time to try to coax my -CURRENT machine into booting again so I can play with this stuff... Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message