Cc: Serge
On 2013/8/17 0:09, Tejun Heo wrote:
> Hello,
>
> On Fri, Aug 16, 2013 at 12:02:04PM -0400, Aristeu Rozanski wrote:
>>> Yeah, that's the correct behavior, if I'm not misunderstanding you,
>>> but to be consistent we also need to allow creating rules which allow
>>> devices which aren't allowed by ancestors. It won't be applicable at
>>> rule creation but may later become effective later on.
>>
>> Oh, I see, it's just matter of allowing to set the desired set or rules
>> locally even if they're not possible at the moment.
>
> Yeah, otherwise, we'd get into situation where setting rules in place
> isn't allowed but moving it out of hierarchy, setting it and then
> moving it back would work, which doesn't make much sense.
>
>> So, considering we drop in sane_behavior the allow + exceptions case,
>> the interface in sane_behavior mode would look like:
>> - policy: {allow_all,deny}
>> writing either will clear the active aw
>> - active_whitelist
>> list of in effect rules, read only
>> - whitelist
>> list of locally set rules, read only
>> - whitelist_add
>> write only, adds rule to the local list and active lists
>> - whitelist_remove
>> write only, removes rule from the local and active lists
>>
>> What you think?
>
> Yeah, I think that should work although you might also need
> active_policy and "effective" might be a better choice as prefix.
As I've started to work on cpuset side, I'm also thinking about
adding cpuset.effective_cpus and cpuset.effective_mems.
> Kay, Lennart, what do you guys think?
>
As Serge is the original author of devcg, let's also see how
Serge feel about the new interfaces?
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
