>From: Vladimir '?-coder/phcoder' Serbinenko <[email protected]> > On 12/26/2010 06:29 AM, [email protected] wrote: > > I will in fact be implementing breaking detection functions into distinct > > functions uniformly, > I'm not fond of "let's change it just because we can". There are much > more real tasks on the project. Come to #grub and I'm sure will find > something for you. > > because there is a deeper issue lurking here. Looks > > to be pure luck no one ran into an unpleasant bug lurking in the existing > > design. > > > > > Please show me the real problem then.
Quite simple, the disk slice scheme detection routines vary in the quality of their detection. In particular, the MSDOS-style detection is *extremely* brittle. The only even mildly distinguishing characteristic it finds is ensuring only the msb of the boot-flag byte is set. The other thing it looks for is the 0xAA55 signature, but that is merely a signal to PC-BIOSes that the disk is bootable; as such *any* bootable disk for a IBM-PC will have that signature, whether or not it is actually using the MSDOS-style header. A 1 in 65536 chance of a false positive is bad. Whereas most of the other schemes have actual magic numbers for the disk-slice scheme, that is *not* merely a flag for whether it is okay to boot from or not (plus checksums, which push them to 1 in 2^32 chance of incorrect detection). Take a look at the attached file, it is ment as a header for a 512KB image (`dd if=/dev/zero count=1023 2>/dev/null | cat sample /dev/stdin > full_sample`). The only reason it will be correctly detected as a SunOS-style disk label is that routine gets tried first, the MSDOS-style detection would take it as valid. I do have a specific goal in mind. Perhaps oddball, but a definite goal. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | [email protected] PGP F6B23DE0 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0 _______________________________________________ Grub-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/grub-devel
