Andrew Clausen wrote: > Hi Robert, > > 2009/10/31 Robert Millan <r...@aybabtu.com>: > >>> What if you have a dual boot setup, with say ntfs and ext3? >>> >> The filesystem module that is embedded in core.img is only for bootstrap >> purposes. Once GRUB can access /boot/grub/, it automatically loads the >> modules required for menu entries. >> > > OK, here's a realistic use case that could hit lots of users: > * grub is installed on an ext3 partition > * the user has OSX installed on an HFS file system (or whatever they > use now) that has stale ext3 signatures > * when grub tries to load the OSX kernel, it has two filesystem > modules loaded: ext2 and hfs. > * the stale signature causes it to misdetect it as hfs, and it fails. > > hfs+ and ext2 use same sector as superblock so it's not a problem > I suppose you could solve this problem by unloading all filesystem > modules except the ones you need at that moment? But Grub doesn't do > that now, right? > > >>> Isn't it easy to just fix the bug? >>> >> First of all, it's not a bug. Filesystems weren't designed to be >> identifiable >> reliably. They could have been, but they weren't, and now we're stuck with >> that. Everything GRUB does to archieve filesystem detection is on a BEST >> EFFORT basis. >> > > I think this is where we disagree... I think that with good > heuristics, you can cover all use cases without any problems. > > (For instance, GNU Parted has a fairly short list of heuristics that > seem to be very reliable -- or they were when I maintained it. The > relevant function is ped_file_system_probe().) > > Alternatively, you could allow the user to specify the file system? > > Or, you could warn when multiple file systems have matching signatures. > > Or you can modify the tools to clear first and last MiB on mkfs which solves problem at the root >> With that in mind, we can find ways in which GRUB will be more succesful at >> identifiing them. For example (and we already do this), the search command >> gives priority to filesystem modules that are already loaded. >> > > This heuristic could have a lot of problems. (See my example above.) > > Any heuristic means that something is wrong. >> Or we can attempt to read a given file when we expect it's there. For >> example, if we're looking for /boot/grub/, we can tell "/boot/grub" to the >> filesystem layer, so that it will require it as a precondition. >> > > I can see that that would work will for some use cases... > > It breaks encapsulation and makes code a lot less maintainable. And just offset clear bug to a lot of strange and weird bugs >> There are many ways to improve this, but making arbitrary assumptions about >> the content of a filesystem (e.g. non-emptyness) doesn't sound like the best >> solution. In this particular case, you can be hit by both false positives >> and false negatives. >> > > Huh? I can't see any way to get "hit" by either for this particular > heuristic. It reduces the number of false positives, and the false > negatives are irrelevant (because an undetected filesystem is > equivalent to an empty one.) > Many filesystems would look having some weird filenames but still having a directory if they are false positives. > Big picture: I'm sorry for being irritating... I know that odd > heuristics are an unpleasant technology to determine whether or not a > computer can boot or not. > We both have similar approaches: try to pick something that works well > under difficult circumstances. I think we differ in the way we think > about use cases. You don't like my heuristic because it has false > positives and false negatives; but I claim that there is no use case > (realistic or unrealistic) in which my heuristic makes things worse. > Some of your proposed heuristics seem reasonable in addition to my own > one, but I think it's clear that adding my heuristic will always make > Grub work better. > Every heurisitic makes code less clear and more prone to bugs and in long run results only in more heurisitc failures.
-- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
