Re: [PATCH] Set size of partition correctly in grub_disk_open()

[Yoshinori K. Okuji]

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