From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LYOp9-0008Bi-4Y for mharc-grub-devel@gnu.org; Sat, 14 Feb 2009 13:01:07 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LYOp7-0008BL-TI for grub-devel@gnu.org; Sat, 14 Feb 2009 13:01:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LYOp7-0008B9-A8 for grub-devel@gnu.org; Sat, 14 Feb 2009 13:01:05 -0500 Received: from [199.232.76.173] (port=45160 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LYOp7-0008B2-4v for grub-devel@gnu.org; Sat, 14 Feb 2009 13:01:05 -0500 Received: from fg-out-1718.google.com ([72.14.220.159]:38927) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LYOp6-0007Kd-7s for grub-devel@gnu.org; Sat, 14 Feb 2009 13:01:04 -0500 Received: by fg-out-1718.google.com with SMTP id l27so66481fgb.30 for ; Sat, 14 Feb 2009 10:01:02 -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:content-type :content-transfer-encoding; bh=+8XDq6mLih+dNozpEHYYJZkMkf041qsi+eRL2jWj9lA=; b=ECHNoyH3JQWfFz0oYUVkycENIGuqKlM6okl212KNg6RAo17bVd/HAMdpU5e0xj7Tbn agzLXlmLm/jFyoR/vlXIRnsLHfT8/D/YjadLeIQ80JKe4wTYgSKPqEvTWwkYPdZwHWRx c6ipU2LHq9lr58I3Fbl2OwUGjl1YNmxJExDL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=BD4FYsXKA3oZOSsWFx5WM8SWwVbpSK3YCnYsJd9MVJaooW4JW16JJ7Wip3RutXN7oZ fVGI7l49nvjpFWtuw8UwYVr0JoBIp+dySmD+4YmnwJwzihc6Fa/XuJs1XkmYGsWX4Fgr e8YfmFLmQ0T95MLOqAO2tY0Th4xsEWTUZRKSg= Received: by 10.86.82.16 with SMTP id f16mr446546fgb.32.1234634461978; Sat, 14 Feb 2009 10:01:01 -0800 (PST) Received: from ?192.168.1.25? (123-48.1-85.cust.bluewin.ch [85.1.48.123]) by mx.google.com with ESMTPS id 3sm4229331fge.52.2009.02.14.10.01.01 (version=SSLv3 cipher=RC4-MD5); Sat, 14 Feb 2009 10:01:01 -0800 (PST) Message-ID: <499706DB.4030001@gmail.com> Date: Sat, 14 Feb 2009 19:00:59 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 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: Design: partitions in partitions 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, 14 Feb 2009 18:01:06 -0000 Hello I would like to implement partition in partitions support (it's on the TODO list) and necessary as a pre-requisite to access solaris' zfs partitions. I would also like to integrate current bsd partition support to it. I propose the following design: Unified naming scheme: purely numerical. It means that (hd0,1,a) becomes (hd0,1,1) get_name is removed from grub_partition_map Unlimited depth support. It means that partitions like fdisk in sun in apple in gpt will be detected (silly but is theoretically possible) Partitions describing whole parent partition or laying outside of parent partition will be filtered An arbitrary limit may be put to avoid endless loop Add pointer to struct grub_disk * in struct grub_partition. Then the prototypes in grub_partition_map are: /* Call HOOK with each partition, until HOOK returns non-zero. */ grub_err_t (*iterate) (grub_partition_t parent, int (*hook) (struct grub_disk *disk, const grub_partition_t partition)); /* Return the partition NUM on the partition PARENT. */ grub_partition_t (*probe) (grub_partition_t parent, int num); For the first level a fake grub_partition_t describing the whole disk will be created What do you think about such a design? Regards Vladimir 'phcoder' Serbinenko