[patch] NetBSD disklabel support for geom_bsd
Dmitry Pryanishnikov
dmitry at atlantis.dp.ua
Sat Mar 18 02:04:41 UTC 2006
Hello!
On Fri, 17 Mar 2006, Paul Mather wrote:
> Just to clear up matters, I wasn't saying your patch did anything wrong,
> I only sought to provide counterexamples to the above two points you
> raised (as you'd suffixed them with question marks). In other words, I
> just wanted to show a concrete example of a valid NetBSD disklabel where
> the "d" partition did not cover the whole HDD, and that there isn't
> always the notion of a "slice" in all NetBSD architectures.
Sure, I'm aware if it. I've just commented NetBSD's partitions layout
on sliced (from FreeBSD's POV) HDD. My patch doesn't rely on particular
partitions order.
> I don't know if the "d" partition not covering the entire HDD affects
> the logic of your patch, or whether it is only the "c" partition that is
> important. (Hopefully, it is the latter.)
Moreover, even 'c' isn't "special" for my patch. Patch uses such a powerful
concept of the GEOM as a provider (the piece of media which our disklabel
describes), and just removes entries which point outside this provider. On
sliceless disks, label is located at start of HDD, describes the whole HDD,
so all entries will lie inside the provider, and my patch won't change such a
label. OTOH, on sliced HDD NetBSD disklabel is located at start of _slice_,
but describes both this slice and media pieces outside the slice (it's
provider), so patch will remove entries which point outside it. This logic is
all about hierarchy, and entry name, say, 'c' or 'd', makes no difference at
all.
Sincerely, Dmitry
--
Atlantis ISP, System Administrator
e-mail: dmitry at atlantis.dp.ua
nic-hdl: LYNX-RIPE
More information about the freebsd-current
mailing list