From owner-freebsd-current@FreeBSD.ORG Fri Mar 17 01:18:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11DFF16A400 for ; Fri, 17 Mar 2006 01:18:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5D0643D46 for ; Fri, 17 Mar 2006 01:18:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 16 Mar 2006 17:18:26 -0800 Message-ID: <441A0E61.5010707@elischer.org> Date: Thu, 16 Mar 2006 17:18:25 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dmitry Pryanishnikov References: <20060317012428.N52721@atlantis.atlantis.dp.ua> In-Reply-To: <20060317012428.N52721@atlantis.atlantis.dp.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [patch] NetBSD disklabel support for geom_bsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2006 01:18:27 -0000 Dmitry Pryanishnikov wrote: > > Hello! > > I've installed NetBSD 3.0 recently on the same HDD with FreeBSD-CURRENT > and found that OSes just don't see each other's partitions. I thought > that it would be convenient for FreeBSD developers if FreeBSD were able > to understand NetBSD's disklabel as we borrow their code occasionally ;) > After detailed analysis I understood the difference between disklabel > formats: > they are essentially the same except 2 points: > > 1) NetBSD people extended partition table to 16 entries vs. our 8. > That's OK, > we have place for 22 entries within 512-byte sector for disklabel > offset 0, > and 18 for offset 64 bytes (Alpha's case). > > 2) (most important) NetBSD disklabel describes partitions not > slice-relative > (like ours), but the whole device-relative. They have no slice > devices, so > their disklabel actually duplicates functionality of device slice > table, and describes both NetBSD partitions and other slices as > partitions. > E.g., for my HDD I've got the following NetBSD disklabel: > > 16 partitions: > # size offset fstype [fsize bsize cpg/sgs] > a: 2097648 147942585 4.2BSD 2048 16384 21872 > b: 2097648 150040233 swap > c: 81931500 147942585 unused 0 0 > d: 312579695 0 unused 0 0 > e: 2088387 63 MSDOS > f: 61440624 152137881 4.2BSD 2048 16384 28704 > g: 10150560 213578505 4.2BSD 2048 16384 28456 > > and so on. > > So, from the FreeBSD's POV the only useful information from NetBSD > disklabel are the entries which point within NetBSD slice (in my example, > a-c,f,g). Others already have FreeBSD's counterparts (my NetBSD slice > is ad0s3, but partition 'd' describes the whole ad0, and 'e' == ad0s1), > and it would be wrong and even dangerous to keep them. > > I've created simple patches against geom_bsd.c for CURRENT and RELENG_6: > > ftp://external.atlantis.dp.ua/FreeBSD/geom_bsd/CURRENT.diff > ftp://external.atlantis.dp.ua/FreeBSD/geom_bsd/RELENG_6.diff > > which implement recognition of NetBSD disklabel only on slicer level > (no support for ioctls == no support for bsdlabel), but IMHO that's > enough - rest can be done from the NetBSD itself. My patches are quite > simple: > > 1. g_bsd_try() modified to accept large (>8) number of partitions; > > 2. g_bsd_taste() accepts NetBSD's slice type 169 and does special > processing for it: truncates partition table to 8 entries, > converts offsets from absolute to slice-relative, and removes > entries which describe areas outside the NetBSD slice. > > I have verified these patches against 2 different NetBSD partition > layouts, they work as expected (for the shown case, create ad0s3a-c, > ad0s3f-g). The only drawback in my solution is that only first 8 > partitions > (of currently 16 NetBSD's) can be represented. If you'll create separate > /, /usr, /var, /home and user-defined partition during NetBSD install, > they'll be: 'a', 'f', 'g', 'h' and 'm' for my HDD layout, and 'm' will > be unreachable from the FreeBSD. I could remap it to the free slot > (e.g. 'd'), but I've decided not to do it, because it could add confusion > IMHO. After all, both slices (FreeBSD and NetBSD) are usually managed > by the same person, so [s]he'll create reasonable NetBSD partition > layout. > > I hope my patch can be useful, and would like to get feedback about it. why not make a completely separate type and allow access to all teh slices with the same partition letters that netBSD uses.. i.e. a g_nbsd type.. > > Sincerely, Dmitry