From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G0Lh1-0000qY-0i for mharc-grub-devel@gnu.org; Tue, 11 Jul 2006 13:06:39 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G0Lgz-0000qJ-Ko for grub-devel@gnu.org; Tue, 11 Jul 2006 13:06:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G0Lgw-0000p1-PP for grub-devel@gnu.org; Tue, 11 Jul 2006 13:06:36 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G0Lgw-0000oy-KS for grub-devel@gnu.org; Tue, 11 Jul 2006 13:06:34 -0400 Received: from [212.85.152.101] (helo=kotoba.storever.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G0LiI-0002lN-CG for grub-devel@gnu.org; Tue, 11 Jul 2006 13:07:58 -0400 Received: from kotoba.oasis.nexedi.com (kotoba.oasis.nexedi.com [212.85.152.101]) by kotoba.storever.com (Postfix) with ESMTP id CB2813C6F4042 for ; Tue, 11 Jul 2006 20:59:00 +0200 (CEST) Received: from [??1] (localhost [127.0.0.1]) by kotoba.storever.com (Postfix) with ESMTP id 554583C6F4041 for ; Tue, 11 Jul 2006 20:59:00 +0200 (CEST) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Tue, 11 Jul 2006 19:06:30 +0200 User-Agent: KMail/1.8.2 References: <87wtarepr8.wl%jeroen@vrijschrift.org> <200607091529.18278.okuji@enbug.org> <87sllatq7j.wl%jeroen@vrijschrift.org> In-Reply-To: <87sllatq7j.wl%jeroen@vrijschrift.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607111906.30670.okuji@enbug.org> X-Bogosity: No, tests=bogofilter, spamicity=0.499996, version=0.17.2 Subject: Re: [PATCH] Set size of partition correctly in grub_disk_open() 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: Tue, 11 Jul 2006 17:06:38 -0000 On Sunday 09 July 2006 23:37, Jeroen Dekkers wrote: > Well, if you consider the total_sectors a private variable, and you > want to have accessor functions for accessing it, then I can > understand your point a bit, but such things will make the kernel > bigger and I thought it was a goal to keep it as small as possible... As small as possible, but as less ugly as possible. I have recognized what happened with GRUB Legacy which only concentrated on how small. So I do not want to make the same mistake again. > I was however thinking about total_sectors as a public variable that > gives the size of the device being opened. I don't really think a > partition is an attribute of a disk (all the partitions might be an > attribute of the disk, but just not a random one). I think it makes > more sense to consider a partition an object of the same class as a > disk, given that they have the same semantics. Having the same semantics does not imply the same structure. I strongly believe that we should keep the hierarchy of device components in raw data, so that we can get full information arbitrarily. > We might have to refactor this code for LVM too, if we consider LVM to > be an advanced partition table. I haven't really looked into > implementing LVM yet, but it's more like a partition table than a > disk. It might make sense to allow people to access it using > (volumegroup, volumename) syntax, like (hardisk, partitionnumber). You > can't just add offsets in grub_disk_check_range like you can with DOS > partitions however. But maybe implementing LVM by adding a new kind of > disk device might be better. IMO, LVM should create a virtual disk, as you did for RAID. This fits into my taste. > Anyway, do you want me to write a grub_disk_get_size() function? Yes, please. Okuji