From owner-freebsd-arch Tue Oct 31 22:38:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 62A1437B4CF; Tue, 31 Oct 2000 22:38:41 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA16cdU26323; Tue, 31 Oct 2000 22:38:39 -0800 (PST) (envelope-from dillon) Date: Tue, 31 Oct 2000 22:38:39 -0800 (PST) From: Matt Dillon Message-Id: <200011010638.eA16cdU26323@earth.backplane.com> To: Warner Losh Cc: John Baldwin , arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: Like to commit my diskprep References: <200011010414.eA14EiV42330@billy-club.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Now that I'm less mobile, I've been able to take a close look at the :code. It looks fairly good and will make diskprep's life easier in :many ways. The new ioctl isn't strictly necessary, but does make life :easier for disklabel to figure things out. I was able to divine this :information from fdisk's output... : :I also see why I thought Matt's code added an mbr on top of that, :which was a pilot error on my part. : :Warner Well, ok... now that someone has actually bothered to look at the patch :-(. The patch really isn't that big a deal. Keep in mind that the existing ioctl, DIOCGDINFO, was hacked to pieces years ago to pull double duty. For some (but not all devices), if there is no valid label the above function will return a virgin label. DIOCGDINFO also aliases the first FreeBSD slice to da0 if there is a valid slice (that isn't dangerously dedicated), god knows why. Even worse, on top of the massive confusion these hacks already cause, the dangerously dedicated label will tend to look like a real label to a DOS program or to fdisk showing FreeBSD on s4, but with a dangerously dedicated label you can't specify slice 4 in any of the FreeBSD disk handling commands, you can only specify the base disk. It makes a twisted sort of sense but the result is mass confusion. The original ioctl should never have been hacked to do double duty or to alias... there really should have been a DIOCGVIRGIN ioctl from the get-go and specifying 'da0' instead of 'da0s1' for a real slice should have never been hacked to work. The DIOCGDINFO ioctl should have been made to return an error if the requested disklabel did not exist rather then fake one up, and we should never have started aliasing da0s1 to da0 in the slice-case. I don't think we can unwind this mess easily, but we can at least make system programs like disklabel behave in a consistent and rational manner. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message