Fri, Dec 15, 2017 at 06:08:13PM CET, dsah...@gmail.com wrote: >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.
It is dev-handle tuple.
