Quoting Li Zefan (lizefan@xxxxxxxxxx):
> 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?
(Hm, I thought I was subscribed to cgroup list, but I'm not seeing any
of these messages, thanks for the cc)
So long as there is a clear way to tell which interface we have,
(and hopefully it won't be changing again) it seems good.
thanks,
-serge
--
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
