From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1PDJFj-0006Sp-Vm for mharc-grub-devel@gnu.org; Tue, 02 Nov 2010 11:58:28 -0400 Received: from [140.186.70.92] (port=36924 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDJFf-0006QM-0l for grub-devel@gnu.org; Tue, 02 Nov 2010 11:58:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDJFb-0002lg-SO for grub-devel@gnu.org; Tue, 02 Nov 2010 11:58:21 -0400 Received: from mail-wy0-f169.google.com ([74.125.82.169]:47476) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDJFb-0002lK-NR for grub-devel@gnu.org; Tue, 02 Nov 2010 11:58:19 -0400 Received: by wyf23 with SMTP id 23so7163132wyf.0 for ; Tue, 02 Nov 2010 08:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yDy4OwF4wg6KOcoinRe0p+4Xd8XGYcN4ct+CSN/fuc0=; b=P+3wD2FaYN2c/v+M0VGzjhigw59JpLAyyVVwzup8gr6nzHlMpZzdF/Zi/3MKncRRhm x2yyHBlI3ymLVwmHzm/TMHYysU2EeXLFvwcRSA5BNFQVG7iINMaEVIsAYL/Yl+Abz9NS MAFPYr2TgPENVBjrRoNUBIHV2mx/kaxOFTwKs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=qMa2Gr6xiWsHqMBDSgomI2WExpHltdAGooZDkJcgsDEkp/WMCjTr+7gXD+w0iZlpg4 JEhnZ/LCgVjyrRFCT86cnr9TWdKGR6qzZyaTxQLAtGsOStPvc4HefNmrw4TOg9f1nz3i obPd6cydh6gLdhWN47QoPzbpooKvob6xnXbnY= Received: by 10.227.153.199 with SMTP id l7mr8616857wbw.133.1288713498116; Tue, 02 Nov 2010 08:58:18 -0700 (PDT) Received: from [147.210.128.210] (laptop-147-210-128-210.labri.fr [147.210.128.210]) by mx.google.com with ESMTPS id x6sm4813830weq.37.2010.11.02.08.58.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Nov 2010 08:58:17 -0700 (PDT) Message-ID: <4CD03517.9000500@gmail.com> Date: Tue, 02 Nov 2010 16:58:15 +0100 From: =?UTF-8?B?R3LDqWdvaXJlIFN1dHJl?= User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.9.2.9) Gecko/20100927 Lightning/1.0b3pre Lanikai/3.1.3 MIME-Version: 1.0 To: grub-devel@gnu.org References: <4C818DBC.10002@gmail.com> <4CCF5BFC.1020907@gmail.com> <4CCFD919.7080205@gmail.com> In-Reply-To: <4CCFD919.7080205@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [RFT] nested partition issues X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 15:58:24 -0000 Hi, The main issue at hand is that, to support NetBSD, we need a working grub-setup for the (very common) case where the NetBSD disklabel is placed in an MSDOS partition. If we need to add yet other ``strcmp (..._partmap->name, ...)'' tests to grub-setup, then we likely have bad abstractions. > Actually now we follow the actual nesting of partitions. Even though > net-/openbsd label metadate is placed inside a partition it still > describes the whole disk as is manifested by it having entries for > partitions not contained inside the partition containing label metadata. > E.g. > (hd0,netbsd6) may be physically contained within (hd0,msdos3) but still > be described inside the label present in second sector (hd0,msdos2). > Place of metadata is secondary to deciding what the nesting of > partitions is. Primary criteria is what this metadata describes. So, basically, as soon as a disklabel uses absolute offsets, this disklabel must be viewed as a top-level disklabel? I'm afraid that this will make things more complicated than they should be. But that's just me. > This is, of course, very unfortunate design but since we support NetBSD > we need such hacks. It's better than being faced with the problems of > kind "My XYZOS handles my partition scheme perfectly but GRUB doesn't > see half of partitions." I did not see reports of such problems (for NetBSD partitions) since I merged the code to ``external'' partitions [1]. Could you please point me to such reports? In the previous implementation, if partition e: in a NetBSD disklabel is discarded, it's because e: describes an ``external'' partition. This external partition is (in all useful cases) described in another partition map, where it is properly nested, hence it will be found by GRUB. Grégoire [1] http://lists.gnu.org/archive/html/grub-devel/2010-07/msg00109.html