On Fri, 2 Oct 2020 14:22:05 -0700 Jakub Kicinski wrote:
> > > Forgot the link ...
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git/log/?h=genetlink-op-policy-export
> > >
> >
> > If it's not too late for you - do you want to merge the two series and
> > pos
On Fri, 2 Oct 2020 14:17:01 -0700 Jakub Kicinski wrote:
> On Fri, 02 Oct 2020 23:00:15 +0200 Johannes Berg wrote:
> > On Fri, 2020-10-02 at 22:59 +0200, Johannes Berg wrote:
> > > On Fri, 2020-10-02 at 13:50 -0700, Jakub Kicinski wrote:
> > > > My thinking was that until kernel actually start
On Fri, 02 Oct 2020 23:00:15 +0200 Johannes Berg wrote:
> On Fri, 2020-10-02 at 22:59 +0200, Johannes Berg wrote:
> > On Fri, 2020-10-02 at 13:50 -0700, Jakub Kicinski wrote:
> > > My thinking was that until kernel actually start using separate dump
> > > policies user space can assume policy 0 i
On Fri, 2020-10-02 at 22:59 +0200, Johannes Berg wrote:
> On Fri, 2020-10-02 at 13:50 -0700, Jakub Kicinski wrote:
> > My thinking was that until kernel actually start using separate dump
> > policies user space can assume policy 0 is relevant. But yeah, merging
> > your changes first would probabl
On Fri, 2020-10-02 at 13:50 -0700, Jakub Kicinski wrote:
>
> My thinking was that until kernel actually start using separate dump
> policies user space can assume policy 0 is relevant. But yeah, merging
> your changes first would probably be best.
Works for me. I have it based on yours. Just upda
On Fri, 02 Oct 2020 22:27:19 +0200 Johannes Berg wrote:
> On Fri, 2020-10-02 at 08:09 -0700, Jakub Kicinski wrote:
> > On Fri, 02 Oct 2020 17:04:11 +0200 Johannes Berg wrote:
> > > > > Yeah, that'd work. I'd probably wonder if we shouldn't do
> > > > >
> > > > > [OP_POLICY]
> > > > > [OP] -> (
On Fri, 2020-10-02 at 08:09 -0700, Jakub Kicinski wrote:
> On Fri, 02 Oct 2020 17:04:11 +0200 Johannes Berg wrote:
> > > > Yeah, that'd work. I'd probably wonder if we shouldn't do
> > > >
> > > > [OP_POLICY]
> > > > [OP] -> (u32, u32)
> > > >
> > > > in a struct with two u32's, since that's qu
From: Jakub Kicinski
Date: Fri, 2 Oct 2020 08:25:17 -0700
> Dave, are you planning a PR to Linus soon by any chance? The conflict
> between this series and Johannes's fix would be logically simple to
> resolve but not trivial :(
Let me apply Johannes's fix to both net and net-next, and then you
On Fri, Oct 02, 2020 at 08:25:17AM -0700, Jakub Kicinski wrote:
> On Fri, 02 Oct 2020 17:13:28 +0200 Johannes Berg wrote:
> > I suppose, I thought you wanted to change it to have separate dump/do
> > policies? Whatever you like there, I don't really care much :)
>
> I just want to make the uAPI fu
On Fri, 2020-10-02 at 08:25 -0700, Jakub Kicinski wrote:
>
> > I suppose, I thought you wanted to change it to have separate dump/do
> > policies? Whatever you like there, I don't really care much :)
>
> I just want to make the uAPI future-proof for now.
Yeah, makes sense.
> At a quick look eth
On Fri, 02 Oct 2020 17:13:28 +0200 Johannes Berg wrote:
> On Fri, 2020-10-02 at 08:09 -0700, Jakub Kicinski wrote:
> > On Fri, 02 Oct 2020 17:04:11 +0200 Johannes Berg wrote:
> > > > > Yeah, that'd work. I'd probably wonder if we shouldn't do
> > > > >
> > > > > [OP_POLICY]
> > > > > [OP] -> (
On Fri, 2020-10-02 at 08:09 -0700, Jakub Kicinski wrote:
> On Fri, 02 Oct 2020 17:04:11 +0200 Johannes Berg wrote:
> > > > Yeah, that'd work. I'd probably wonder if we shouldn't do
> > > >
> > > > [OP_POLICY]
> > > > [OP] -> (u32, u32)
> > > >
> > > > in a struct with two u32's, since that's qu
On Fri, 02 Oct 2020 17:04:11 +0200 Johannes Berg wrote:
> > > Yeah, that'd work. I'd probably wonder if we shouldn't do
> > >
> > > [OP_POLICY]
> > > [OP] -> (u32, u32)
> > >
> > > in a struct with two u32's, since that's quite a bit more compact.
> >
> > What do we do if the op doesn't have
On Fri, 2020-10-02 at 08:03 -0700, Jakub Kicinski wrote:
> > Huh, I even CC'ed you I think?
>
> I filter stuff which is to:netdev cc:me and get to it when I read the
> ML. There's too much of it.
Ah, ok :)
> > Yeah, that'd work. I'd probably wonder if we shouldn't do
> >
> > [OP_POLICY]
> >
On Fri, 02 Oct 2020 16:58:33 +0200 Johannes Berg wrote:
> > > Or just give them both? I mean, in many (most?) cases they're anyway
> > > going to be the same, so with the patches I posted you could just give
> > > them the two different policy indexes, and they can be the same?
> >
> > Ah, I mis
> > Or just give them both? I mean, in many (most?) cases they're anyway
> > going to be the same, so with the patches I posted you could just give
> > them the two different policy indexes, and they can be the same?
>
> Ah, I missed your posting!
Huh, I even CC'ed you I think?
https://lore.ke
On Fri, 02 Oct 2020 16:42:09 +0200 Johannes Berg wrote:
> On Fri, 2020-10-02 at 07:40 -0700, Jakub Kicinski wrote:
>
> > > I suppose you could make an argument that only some attrs might be
> > > accepted in doit and somewhat others in dumpit, or perhaps none in
> > > dumpit because filtering wasn
On Fri, 2020-10-02 at 07:40 -0700, Jakub Kicinski wrote:
> > I suppose you could make an argument that only some attrs might be
> > accepted in doit and somewhat others in dumpit, or perhaps none in
> > dumpit because filtering wasn't implemented?
>
> Right? Feels like it goes against our strict
On Fri, 02 Oct 2020 08:29:27 +0200 Johannes Berg wrote:
> On Thu, 2020-10-01 at 17:36 -0700, Jakub Kicinski wrote:
> > Do we need support for separate .doit and .dumpit policies?
> > Or is that an overkill?
>
> I suppose you could make an argument that only some attrs might be
> accepted in doit
On Thu, 2020-10-01 at 17:36 -0700, Jakub Kicinski wrote:
> On Thu, 1 Oct 2020 15:59:23 -0700 Jakub Kicinski wrote:
> > Hi!
> >
> > The objective of this series is to dump ethtool policies
> > to be able to tell which flags are supported by the kernel.
> > Current release adds ETHTOOL_FLAG_STATS f
On Thu, 1 Oct 2020 15:59:23 -0700 Jakub Kicinski wrote:
> Hi!
>
> The objective of this series is to dump ethtool policies
> to be able to tell which flags are supported by the kernel.
> Current release adds ETHTOOL_FLAG_STATS for dumping extra
> stats, but because of strict checking we need to m
Hi!
The objective of this series is to dump ethtool policies
to be able to tell which flags are supported by the kernel.
Current release adds ETHTOOL_FLAG_STATS for dumping extra
stats, but because of strict checking we need to make sure
that the flag is actually supported before setting it in
a r
22 matches
Mail list logo
