On 09/04/2015 01:34 PM, Florian Weimer wrote:
....>>> It will also be very painful to add additional bits. We went through
>>> this with the CPU affinity mask, and it still hurts it. Please use a
>>> more sensible interface from the start. :)
>>
>> Any suggestions?
>
> It's difficult. I don't know what kind of programming model you
> expect. Could glibc use these bits for its own implementation? Or
> OpenSSL?
Our expectation is that there will be a central "allocator" for these
bits for mixed-use, like when two libraries want to control a portion of
the address space for their purposes.
Applications will also be completely free to implement their own, like
with a language runtime.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
....>>> It will also be very painful to add additional bits. We went through
>>> this with the CPU affinity mask, and it still hurts it. Please use a
>>> more sensible interface from the start. :)
>>
>> Any suggestions?
>
> It's difficult. I don't know what kind of programming model you
> expect. Could glibc use these bits for its own implementation? Or
> OpenSSL?
Our expectation is that there will be a central "allocator" for these
bits for mixed-use, like when two libraries want to control a portion of
the address space for their purposes.
Applications will also be completely free to implement their own, like
with a language runtime.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/