Date: Fri, 25 Oct 2002 16:12:40 +0100 (BST) From: Mark Valentine <mark@thuvia.demon.co.uk> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: freebsd-arch@freebsd.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_dis Message-ID: <200210251512.g9PFCenT072317@dotar.thuvia.org> In-Reply-To: <17783.1035552121@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Poul-Henning Kamp <phk@critter.freebsd.dk>
> 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 <mark@thuvia.co.uk> <http://www.thuvia.co.uk>;
"Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses
"We're kind of stupid that way." *munch* *munch* and endorses FreeBSD
-- <http://www.calvinandhobbes.com>; <http://www.freebsd.org>;
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?200210251512.g9PFCenT072317>