On Sat, Jul 18, 2009 at 11:28:58PM +0200, Vladimir 'phcoder' Serbinenko wrote: > > I don't understand what you mean here. > Let's take a common example of cdrom. Most of the users and developers > are accustomed to a cdrom holding one filesystem. On macs however cds > are partitioned and not being able to access all the partitions is a > problem for end user. Such situations are probably common. If we ditch > has_partitions altogether the only negative side effect will be that > in some weird configurations unpartitioned media may appear to have > partitions but whole media is still accessible. Additionally it > simplifies and makes kernel smaller
I'm not sure they're so weird. But we could still do it. Pavel, what do you think? > >> > I'm not sure there's much we can do about this. Using heuristics sounds > >> > like > >> > it will make the solution worse than the problem. I don't care much > >> > about > >> > Microsoft filesystems, but I'd hate to see GRUB fail on a completely sane > >> > ext3 inside msdos label because it happened to look like FAT in raw disk > >> > at > >> > the same time. > >> The approach proposed by Collin avoids such problems since correct > >> pc_partition_map is always detected as such. > > > > I haven't looked at the source code, but what he said is we can determine if > > an MBR is valid by checking the bootable flag, and this is not always so. > I don't see any problem. He said: checking that bootable flags of all > partitions are either set (0x80) or unset (0x0) and not another value Oh, that's different. I think it's fine provided that: - None of the commonly used free partitioning tools uses an illegal value. - We fail gracefully and let the user know why. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel