Re: Two Small Patches (x86 VolId & Sun Label Checking)

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3145 bytes --]

On 12/29/2010 07:25 AM, ehem+grub@m5p.com wrote:
>> From: Vladimir '?-coder/phcoder' Serbinenko <phcoder@gmail.com>
>> On 12/26/2010 10:15 PM, ehem+grub@m5p.com wrote:
>>     
>>> 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.
>>>       
>   
>> Actually 1 in 2^(7*4+16) =2^44 in you take into account the both checks
>> and consider every possible sector equiprobable. While this is a
>> problem, it's design problem of this partitioning label. More sanity
>> checks are possible but they would be heuristics and increase the
>> possibility of false negative. So every additional sanity check is to be
>> considered on case-by-case basis.
>>     
> Alas, seeing how every possible sector is very much *not* equiprobable,
>   
Then you need to havethe information about distribution before even
speaking about any probabilities. Otherwise these "probabilities" are
good only for fortune-telling.
>
>> Improving quality of partmap detection is a good goal but be aware of
>> the price of heuristics.
>>     
> That isn't my thinking. I was thinking of having it test for the various
> schemes first, then choosing the best fit. While trying multiple schemes
> is viable for grub_partition_iterate(), it doesn't work when installing
> boot code or attempting to do partition modification (since both of these
> *must* know in order to function).
>
>   
When doing grub-setup then the philosophy is: "do no harm". It must
abort when it sees anything unusual. GRUB can't have a super cow
intelligence to magically sort all possible weird stuff. So sometimes we
have to abort rather than risk damaging any data (with optional override
options).
As for partmap the user tells explicitly which partition table he means.
E.g:
parttool hd0,msdos1 boot+
So there is no problem here.
> Organizational item here. Is the existing layout of <task>/<arch> for the
> best? (task would be boot/partmap/parttool, arch is pretty much every .c
> file in grub-core/partmap) I wonder if perhaps a structure like
> <arch>/<task> would work better?
>
>   
Shuffling the files around without anything more than "it looks slightly
better for me" is usually useless. We, the current developpers, find the
current layout convenient. If do-o-cratically the consensus on changing
of layout would be established it can be done, however I don't see it happen

While the sensible checks would be accepted, pushing tolerances of
heuristics is of little use. Tell the real stuff if you want to convince me


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]