grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: status grub2 port of grub-legasy map command


From: Vladimir 'phcoder' Serbinenko
Subject: Re: status grub2 port of grub-legasy map command
Date: Thu, 14 May 2009 17:01:14 +0200

On Thu, May 14, 2009 at 4:03 PM, Pavel Roskin <address@hidden> wrote:
> On Thu, 2009-05-14 at 08:49 +0200, Vladimir 'phcoder' Serbinenko wrote:
>> Hello, I had two clear oppositions which weren't resolved. I don't
>> believe that merge patches screwing up the pendin oppositions is a
>> good practice. The opposition about declaration is based on another
>> handlers how it is used accross grub. Opposition about calling
>> biosdisk is technically relevant. Or perhaps I should start committing
>> anything without discussion?
>> Here is a fix patch. Could I commit it even if there will be oppositions?
>
> I'm sorry, I didn't realize you were opposed to the patch.  I assumed
> that you just wanted to make some improvements.  Nobody was against the
> drivemap command in principle.  The discussion was about minor details.
Ok. Sorry for my harsh reaction. Now I'm under a lot of stress.
>
> I'm fine with the change from "const void" to "const char", but we need
> to remove a preceding comment about void labels.
It's not that I'm opposed to void in principle. Just using the same
constructions to do the same things in different files makes code
easier to learn and port
>
> As for the parse_biosdisk() change, I'd like to see an explanation.
The explanation is that if user uses ata or usbms code and code calls
biosdisk, BIOS may issue a command which may conflict with ata/usbms.
Unfortunately it's not a scenario we're able to circumvent (BIOS is
headache) so I prefer to err on a safe side
> I
> understand you want to allow remapping invalid devices, and I'm fine
> with that.  But then list_mappings() should be changed accordingly and
> revparse_biosdisk() may need to be eliminated.
>
Ok. Will have a look at it this weekend
>> > Logic in uninstall_int13_handler() has been fixed.
>> >
>> Which logic fix?
>> Other than variable rename it seems to be identical to Javier Martín's patch
>
> No, it was:
>
>  if (grub_drivemap_int13_oldhandler != 0)
>    return GRUB_ERR_NONE;
>
> The code was refusing to uninstall the handler if it was installed.
>
> I checked the logic by patching the chainloader code to return instead
> of giving control to the bootsector.
>
Ok, didn't notice it. Thanks
> --
> Regards,
> Pavel Roskin
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko




reply via email to

[Prev in Thread] Current Thread [Next in Thread]