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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
