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

Re: [Xen-devel] [PATCH V2 04/12] Refactor read_file() so it can be shared.

On Wed, Aug 6, 2014 at 11:20 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 06.08.14 at 20:38, <roy.franz@xxxxxxxxxx> wrote:
>> On Thu, Jul 24, 2014 at 12:09 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 22.07.14 at 02:43, <roy.franz@xxxxxxxxxx> wrote:
>>>> The read_file() function updated some multiboot specific data structures
>>>> as it was loading a file.  These changes make read_file() more generic,
>>>> and create a load_file() wrapper for x86 that updates the multiboot
>>>> data structures.  read_file() no longer does special handling of
>>>> the configuration file, as this was only needed to avoid adding
>>>> it to the multiboot structures.  read_file() and load_file() return
>>>> error codes rather than directly exiting on error to facilicate
>>>> sharing.  Different architectures may require different max allocation
>>>> addresses so take that as an argument.
>>> Unless you expect an architecture to pass in different values on
>>> different invocations this clearly can be a #define rather than a
>>> function parameter.
>> I'll remove the argument - Ian's module freeing patch removes the need
>> for this.
> Actually, didn't I see a later patch actually making use of this now
> being an argument (passing a different value than the constant one
> used in this patch)?
> Jan
There wasn't - I was using a constant for now, as determining the real max value
would have been tricky and fragile, so I punted on that, as I figured
there would be
a better way to resolve this issue.  Ian's fix for this problem is the
right one,
so this is all going away.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.