Hi Laura,
On Wed, Jun 08, 2016 at 12:14:12PM -0700, Laura Abbott wrote:
For now I'm just going to focus on comments not about the heap ID mapping
because I'm leaning towards dropping the heap ID mapping.
Fair enough. Like you said, giving userspace enough information to just
figure out the r
On 06/08/2016 08:34 AM, Brian Starkey wrote:
Hi,
I'm finding "usage_id" a bit confusing - there's not a very clear
distinction between usage_id and heap ID.
For instance, ION_IOC_USAGE_CNT claims to return the number of usage
IDs, but seems to return the number of heaps (i.e. number heap IDs, s
On 06/08/2016 06:50 AM, Liviu Dudau wrote:
On Mon, Jun 06, 2016 at 11:23:33AM -0700, Laura Abbott wrote:
From: Laura Abbott
The Ion ABI for heaps is limiting to work with for more complex systems.
Heaps have to be registered at boot time with known ids available to
userspace. This becomes a t
Hi,
I'm finding "usage_id" a bit confusing - there's not a very clear
distinction between usage_id and heap ID.
For instance, ION_IOC_USAGE_CNT claims to return the number of usage
IDs, but seems to return the number of heaps (i.e. number heap IDs, some
of which might be usage_ids).
Similarly,
On Mon, Jun 06, 2016 at 11:23:33AM -0700, Laura Abbott wrote:
> From: Laura Abbott
>
>
> The Ion ABI for heaps is limiting to work with for more complex systems.
> Heaps have to be registered at boot time with known ids available to
> userspace. This becomes a tight ABI which is prone to breakag
From: Laura Abbott
The Ion ABI for heaps is limiting to work with for more complex systems.
Heaps have to be registered at boot time with known ids available to
userspace. This becomes a tight ABI which is prone to breakage.
Introduce a new mechanism for registering heap ids dynamically. A base
6 matches
Mail list logo
