From owner-freebsd-arch Tue Oct 31 15:57:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 37D0237B4C5; Tue, 31 Oct 2000 15:57:13 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id QAA22202; Tue, 31 Oct 2000 16:53:56 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpdAAAvlaioR; Tue Oct 31 16:53:45 2000 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id QAA19282; Tue, 31 Oct 2000 16:56:57 -0700 (MST) From: Terry Lambert Message-Id: <200010312356.QAA19282@usr09.primenet.com> Subject: Re: Like to commit my diskprep To: obrien@FreeBSD.ORG Date: Tue, 31 Oct 2000 23:56:57 +0000 (GMT) Cc: imp@village.org (Warner Losh), arch@FreeBSD.ORG In-Reply-To: <20001031132945.B28476@dragon.nuxi.com> from "David O'Brien" at Oct 31, 2000 01:29:46 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I'd like to commit my diskprep program and go fix all the cross > > references in the man pages to include a pointer to it. > > My reservation is do we need yet another official way to prepare disks? > I'm thinking from a tech support stand point -- too many choice just > causes confusion. > > Since Matt's bits do fix the basic problem, is diskprep OBE except maybe > as a wrapper for fdisk & disklabel? You mean "yet another official way", like seperate fdisk and disklabel utilities? Isn't the following obvious to everyone: 1) fdisk and disklabel are tools for dividing a disk into N extents. 2) The only difference a user gives a damn about is that for one of these tools, N=4, and for the other, N!=4, and the user doesn't even care about that, if you were to parameterize it. 3) The kernel has to know about these structure in scope, or it couldn't read the things to externalize devices in the first place. 4) It's pretty easy to just eyeball the interfaces, and come up with an abstract ioctl() that can read and write any partitioning scheme known to the kernel, by scheme ID. 5) It'd be pretty easy to pull a list of permissable schemes out of the kernel by pulling it back across the user kernel boundary, from the kernel code to which the schemes must be known anyway. So why isn't there just one tool in user space that ioctl()'s down to see what's allowed, ioctl()'s down to read what's there, and ioctl()'s down to write out and/or delete stuff -- a single program that is nothing more than a shell for doing ioctl()'s, and knows how to do everything the kernel knows how to do? To hell with disklabel and all these other nasty programs that can get out of sync with the kernel's idea of the on disk partitioning layout, and confuse the user with "it's a slice!", "no! It's a partititon!" , "no, it's a DOS extended partition, which is a slice because we used the name ``partition'' before 1981!". Ugh. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message