From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lg1Y9-0000E2-Pd for mharc-grub-devel@gnu.org; Sat, 07 Mar 2009 13:47:05 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lg1Y7-0000Cq-2V for grub-devel@gnu.org; Sat, 07 Mar 2009 13:47:03 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lg1Y6-0000CY-Jm for grub-devel@gnu.org; Sat, 07 Mar 2009 13:47:02 -0500 Received: from [199.232.76.173] (port=52040 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lg1Y6-0000CU-Fd for grub-devel@gnu.org; Sat, 07 Mar 2009 13:47:02 -0500 Received: from fg-out-1718.google.com ([72.14.220.152]:20567) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lg1Y5-0000Og-Re for grub-devel@gnu.org; Sat, 07 Mar 2009 13:47:02 -0500 Received: by fg-out-1718.google.com with SMTP id l27so661271fgb.30 for ; Sat, 07 Mar 2009 10:47:01 -0800 (PST) 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=ceTJiHwq6esgsnzEPWbGIvgWJdIVKKv2UpX3ze2yGEY=; b=ptkvqoOWyUUPZd5UxyHqhiVhIpv4Bij7gaxVZmtCOwDIcy6oT1FVCgFN4kECYi5zOs hrUixZbVAttvu6SFXUgJ7ZI2dLkrHWdcGaBflhhpLKg1hxIuQkSG/kygO9u7c6r4xYpj DtzCqVO3+2CTkRmJDWgjecygp2ca767yFdSW8= 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=B96TB97d2l7V+4F9SPjlemkd6TJkwYGoitORBcYVC4UWR/ALbxUSf34yJV09sy0h+v GXMT+Ypu2zIYUtE/uCeUq242cFRPiosqQUbQF9wXC69PPilTtpierWdK0hUrmLQD10yB USPGOQ3q/CgtS305OrX8sEZyni20qfM+xlzSI= Received: by 10.86.72.15 with SMTP id u15mr2822045fga.33.1236451621010; Sat, 07 Mar 2009 10:47:01 -0800 (PST) Received: from ?192.168.1.25? (181-74.0-85.cust.bluewin.ch [85.0.74.181]) by mx.google.com with ESMTPS id 4sm1314761fgg.16.2009.03.07.10.47.00 (version=SSLv3 cipher=RC4-MD5); Sat, 07 Mar 2009 10:47:00 -0800 (PST) Message-ID: <49B2C11E.6030304@gmail.com> Date: Sat, 07 Mar 2009 19:46:54 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: <49B28BA6.3030109@gmail.com> <20090307153815.GA15220@thorin> <49B29AEE.4000409@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [Design] nested partitions: Unify grub_partition and grub_disk X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 18:47:03 -0000 Bean wrote: > Hi, > >> Hello. I was looking into nested partitions issue and propose to unify grub_partition and grub_disk. In this case when a code calls grub_disk_read with a >grub_disk_t which represents a partition it will correct the offset and call grub_disk_read with underlying partition or disk. In this way not only nested partitions >become natural but also conceptually similar fields of total_sectors and len become unified. As it's an important design change I send this e-mail before coding it > > Actually, this is already how it works. grub_disk has a partition > pointer, which indicate if it is partition or disk, and > grub_disk_adjust_range adjust the offset for partition. > > My suggestion is, always treats grub_disk as a partition, and use the > offset. For the root partition, offset is 0 so we get the whole disk. > The problem with such a design is that the partition code would always have to add parent partition offset to the start of subpartitions. It's something that I would like to hide from partition code mainly because people don't usually care if their code works well in nested partition environments and its cleaner if partition code doesn't need to not whether it divides a disk or subdivides a partition. In my proposition at each step I call a function which naturally resolves the current level of indirection. E.g. if we have sun partition in fdisk partition on biosdisk I call: 1) device->partition->probe it gives the offset 2) device->parent->partition->probe it gives the second offset 3) device->parent->parent->dev->read As you see at every step I just resolve a level of indirection > > This flag could be useful sometimes. For example, in raid devices, the > first disk may contain partition table, but we shouldn't use it. > I'm not familiar with raid but could it be that boot partition is at the first disk of raid just after the partition map. Then to read it we don't need raid modules. I don't see why such a usage case should be specifically excluded And don't raid disk contain a volume header? If they do how can they contain the partition table in the usual place Also existence of (hd0,1) doesn't prevent you from accessing (hd0) -- Regards Vladimir 'phcoder' Serbinenko