On 02/12/2018 12:22 PM, Alexey Skidanov wrote:

On 02/12/2018 09:52 PM, Laura Abbott wrote:
On 02/12/2018 11:11 AM, Alexey Skidanov wrote:

On 02/12/2018 08:42 PM, Laura Abbott wrote:
On 02/10/2018 02:17 AM, Alexey Skidanov wrote:
Current ion defined allocation ioctl doesn't allow to specify the
allocation alignment. CMA heap allocates buffers aligned on buffer size
page order.

Sometimes, the alignment requirement is less restrictive. In such
providing specific alignment may reduce the external memory
and in some cases it may avoid the allocation request failure.

I really do not want to bring this back as part of the regular
Yes, I know it was removed in 4.12.
Having an alignment parameter that gets used for exactly
one heap only leads to confusion (which is why it was removed
from the ABI in the first place).
You are correct regarding the CMA heap. But, probably it may be used by
custom heap as well.

I can think of a lot of instances where it could be used but
ultimately there needs to be an actual in kernel user who wants

The alignment came from the behavior of the DMA APIs. Do you
actually need to specify any alignment from userspace or do
you only need page size?
Yes. If CMA gives it for free, I would suggest to let the ion user to

I'm really not convinced changing the ABI yet again just to let
the user decide is actually worth it. If we can manage it, I'd
much rather see a proposal that doesn't change the ABI.
I didn't actually change the ABI - I just use the "unused" member:
struct ion_allocation_data {
@@ -80,7 +79,7 @@ struct ion_allocation_data {
         __u32 heap_id_mask;
         __u32 flags;
         __u32 fd;
-       __u32 unused;
+       __u32 align;

Something that was previously unused is now being used. That's a change
in how the structure is interpreted which is an ABI change, especially
since we haven't been checking that the __unused field is set
to 0.

As an alternative, I may add __u64 heap_specific_param - but this will
change the ABI. But, probably it makes the ABI more generic?

Why does the ABI need to be more generic? If we change the ABI
we're stuck with it and I'd like to approach it as the very last

devel mailing list

Reply via email to