[apparmor] [RFC] How to handle multiple opencl implementations?
Vincas Dargis
vindrg at gmail.com
Wed May 9 16:55:19 UTC 2018
On 5/9/18 5:05 PM, Jamie Strandboge wrote:
> On Tue, 2018-05-08 at 23:09 -0700, John Johansen wrote:
>>
>> On top of each of the opencl-XXX abstractions I think it would
>> be worth having a generic opencl abstraction that includes
>> the various sub-abstractions, its wide now but the intent
>> will be to tighten it up with conditionals once better support
>> lands.
>
> This could work well.
>
Let me check if I got it right.
So we have implementation-specific abstractions:
opencl-pocl,
opencl-beignet,
opencl-whatever
And:
opencl
that includes all of above by default? In the future, it will have
conditional support to disable/enable specific subset of OpenCL
implementations? (should be TODO: implement conditional switches to
select OpenCL implementations).
The only problem I see here is the generic `/etc/OpenCL/** r,` rule that
is used to figure out what OpenCL implementations are available.
If profile author includes, let's say, only `opencl-beignet`, it will
have to write these common rules by himself?
Maybe we need `opencl-common`, that would be included by all of specific
abstractions?
I understand that in the future, with proper conditional support, there
will be no issue I have mentioned as every profile could just include
`opencl` with proper conditionals defined, and `opencl` will have all
these common rules.
So:
A. we have additional opencl-common?
B. we don't care too much yet and expect generic `opencl` abstraction to
be used with all implementations included by default _and_ common rules
inline, until we get conditional support?
More information about the AppArmor
mailing list