[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 1/2] device_tree: Add qemu_devtree_setprop_sized

From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 1/2] device_tree: Add qemu_devtree_setprop_sized_cells() utility function
Date: Wed, 26 Jun 2013 09:49:51 +0100

On 26 June 2013 00:38, David Gibson <address@hidden> wrote:
> On Mon, Jun 24, 2013 at 12:02:39PM +0100, Peter Maydell wrote:
>> On 24 June 2013 11:56, Alexander Graf <address@hidden> wrote:
>> > This looks pretty complicated for something actually quite
>> > simple: All you want is to pass in a number of 64bit values,
>> > rather than 32bit ones, right?
>> Nope. If the device tree blob says #address-cells is 1
>> and #size-cells is 1, then I want to pass in values to
>> go in 32 bit cells. If it says #address-cells is 2 but
>> #size-cells is still 1, then I want to pass in a value
>> for a 64 bit cell then one for a 32 bit cell. If they're
>> both 2 then I want to pass in values for two 64 bit
>> cells.
> Hmm.. the property certainly needs to be constructed that way.  But I
> think Alex's point is that you could make the arguments all 64-bit,
> and then truncate them in the generated property.

Er, the arguments *are* all 64 bits and truncated
in the generated property:
+ * @...: 0-terminated list of uint32_t number-of-cells, uint64_t value pairs

> There's a bigger problem, though, that exists with both versions.  In
> general people expect integer arguments like this not to care too much
> about the exact integer type, because it will be promoted to the right
> thing.  Except with varargs it won't.  So if you ever have a
> notionally 64-bit address that happens to fit in a 32-bit variable and
> you pass that it, this function will be broken.  And the worst of it
> is, it'll work most of the time, until you happen to hit the wrong ABI
> and parameter combination :(.

Do you have a suggested improvement to the API to avoid this?

-- PMM

reply via email to

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