[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN v2 03/11] xen/arm: domain_build: Replace use of paddr_t in find_domU_holes()
On 20/01/2023 09:48, Julien Grall wrote: Hi, On 19/01/2023 23:02, Stefano Stabellini wrote:On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:bankbase, banksize and bankend are used to hold values of type 'unsigned long long'. This can be represented as 'uint64_t' instead of 'paddr_t'. This will ensure consistency with allocate_static_memory() (where we use 'uint64_t' for rambase and ramsize). In future, paddr_t can be used for 'uin32_t' as well to represent 32bit physical addresses. Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>I saw that Julien commented about using unsigned long long. To be honest, given that we typically use explicitly-sized integers (which isa good thing)From the CODING_STYLE: "Fixed width types should only be used when a fixed width quantity is meant (which for example may be a value read from or to be written to a register)." This is also how we used it in the Arm port so far.and unsigned long long is always uint64_t on all architectures, I can see the benefits of using uint64_t here.From my understanding of the C spec, the only requirement is that "unsigned long long" can fit a 2^64 - 1. So it may technically be bigger than 64-bit.At the same time, I can see that the reason for change the type here is that we are dealing with ULL values, so it would make sense to use unsigned long long. > I cannot see any big problem/advantages either way, so I am OK with this patch. (Julien, if you prefer unsigned long long I am fine with that also.)I don't mind too much here.Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> Committed. Cheers, -- Julien Grall
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |