Date: Sat, 18 Mar 2006 04:04:37 +0200 (EET) From: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> To: Paul Mather <paul@gromit.dlib.vt.edu> Cc: freebsd-current@freebsd.org Subject: Re: [patch] NetBSD disklabel support for geom_bsd Message-ID: <20060318034927.L40573@atlantis.atlantis.dp.ua> In-Reply-To: <1142644924.4967.19.camel@zappa.Chelsea-Ct.Org> References: <20060317204723.7F91416A51F@hub.freebsd.org> <1142636322.1188.15.camel@zappa.Chelsea-Ct.Org> <20060318022800.S40573@atlantis.atlantis.dp.ua> <1142644924.4967.19.camel@zappa.Chelsea-Ct.Org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@atlantis.dp.ua nic-hdl: LYNX-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060318034927.L40573>