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. On Sun, Mar 8, 2009 at 12:03 AM, phcoder <phco...@gmail.com> wrote: > I forgot to speak about another question: partition naming. I see 2 > possibilities > 1) purely numeric unified naming scheme. It means that > (hd0,1,a) becomes (hd0,1,1) > On one hand mixed number-letter scheme is similar to what freebsd uses but > on the other hand numerical scheme is versatile and allows unlimited > nestedness. And I don't see why we would use a scheme specific to one of > many supported OSes. > 2) Every partition map is allowed to pick the name that it likes as long as > it contains no comma. In this way we would need to keep partition-name > parsing functions in partitition map modules. It means that this code would > be duplicated. But this scheme is better in the cases when partition map has > no numbering scheme but instead has labels attached to partitions. But in > this case IMO search command should be used find the partition > > I personally would prefer the first way I'm fine with names like (hd0,1,1). >> >> Also an interesting question is how would "has_partitions" field be >> handled in this scheme. > > Just ignored. It's actually used only to optimise some code out based on the > assumption that some media has no partitions. Performance gain is negligible > but if this assumption doesn't hold true grub won't be able to access the > partitions which are really here. Famous example is a cdrom. Most people > would assume that cdrom has no partitions. But on powerpc bootable cdroms > use APM This flag could be useful sometimes. For example, in raid devices, the first disk may contain partition table, but we shouldn't use it. -- Bean _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel