On 12/13/17 5:46 PM, Jakub Kicinski wrote: > On Wed, 13 Dec 2017 19:42:41 +0100, Jiri Pirko wrote: >>>>>> I plan to do it as a follow-up patch. But this is how things are done >>>>>> now and have to continue to work. >>>>> >>>>> Why is that? You are introducing the notion of a shared block with this >>>>> patch set. What is the legacy "how things are done now" you are >>>>> referring to? >>>> >>>> Well, the filter add/del should just work no matter if the block behind is >>>> shared or not. >>> >>> My argument is that modifying a shared block instance via a dev should >>> not be allowed. Those changes should only be allowed via the shared >>> block. So if a user puts adds a shared block to the device and then >>> attempts to add a filter via the device it should not be allowed. >> >> I don't see why. The handle is the qdisc here. > > If you look at it from Linux perspective that makes sense. For people > coming from switching world the fact that we use qdiscs as a handle for > ACL blocks is an implementation detail.. is that the argument here? >
In a sense, yes. When configuring the filter, the primary command line argument is the device. The qdisc is then derived from it and is an implementation detail.