Date: Tue, 31 Oct 2000 22:38:39 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Warner Losh <imp@village.org> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: Like to commit my diskprep Message-ID: <200011010638.eA16cdU26323@earth.backplane.com> References: <XFMail.001031195213.jhb@FreeBSD.org> <200011010414.eA14EiV42330@billy-club.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011010638.eA16cdU26323>