Re: [patch] NetBSD disklabel support for geom_bsd

From: Dmitry Pryanishnikov <dmitry_at_atlantis.dp.ua>
Date: Sat, 18 Mar 2006 04:04:37 +0200 (EET)
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
Received on Sat Mar 18 2006 - 01:04:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:53 UTC