[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