Re: [PATCH v4 14/24] arm/acpi: Prepare EFI system table for Dom0

[Shannon Zhao <zhaoshenglong@huawei.com>]

On 2016/3/1 20:49, Stefano Stabellini wrote:
> On Tue, 1 Mar 2016, Jan Beulich wrote:
>>>>> > >>> On 01.03.16 at 03:35, <zhaoshenglong@huawei.com> wrote:
>> > 
>>> > > 
>>> > > On 2016/2/29 22:36, Jan Beulich wrote:
>>>>>>> > >>>>> On 29.02.16 at 15:25, <stefano.stabellini@eu.citrix.com> wrote:
>>>>>> > >>> > On Mon, 29 Feb 2016, Jan Beulich wrote:
>>>>>>>> > >>>> >> Also it doesn't look very nice to me to (ab)use xz's CRC32 code
>>>>>>>> > >>>> >> here; I don't know who has suggested doing so.
>>>>>> > >>> >  
>>>>>> > >>> > It was suggested by Julien.
>>>>>> > >>> > 
>>>>>> > >>> > I agree that including ../../../common/xz/crc32.c seems a bit fragile
>>>>>> > >>> > but introducing another copy of xz_crc32 seems even worse to me (see
>>>>>> > >>> > http://marc.info/?l=xen-devel&m=144775375427921&w=2). Maybe you have a
>>>>>> > >>> > better suggestion?
>>>> > >> Well, at some point there was talk of ARM not wanting to
>>>> > >> ExitBootServices() as early as x86 does. In that case there
>>>> > >> would be a CRC32 function among the various boot services
>>>> > >> ones.
>>>> > >> 
>>> > > At this point, I think it already ExitBootServices() while it's creating
>>> > > Dom0.
>> > 
>> > I understand that's the case today, hence my saying "at some
>> > point there was talk of ...".
>> > 
>>>> > >> The other option would be to have a generic crc32() function,
>>>> > >> and maybe make xz use it.
>>> > > Ok, I'll go for this way.
>> > 
>> > Well, for the avoidance of doubt: With the code moving into an
>> > ARM specific file, if Stefano is fine with the xz hack, I certainly
>> > won't insist on you adding a separate crc32().
> Having a generic crc32() function like you suggested would be nicer than
> the xz hack. If Shannon is OK with doing that, it would be best.
Since this will introduce more changes, I want to stay with current way.

Thanks,
-- 
Shannon


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel