| Message ID | 20230725162205.27526-1-donald.hunter@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | tools/net/ynl: Add support for netlink-raw families | expand |
On Tue, 25 Jul 2023 17:22:02 +0100 Donald Hunter wrote: > This patchset adds support for netlink-raw families such as rtnetlink. > > The first patch contains the schema definition. > The second patch extends ynl to support netlink-raw > The third patch adds rtnetlink addr and route message types Haven't gotten to it today, unfortunately, but very exciting!
On Tue, Jul 25, 2023 at 05:22:02PM +0100, Donald Hunter wrote: > This patchset adds support for netlink-raw families such as rtnetlink. > > The first patch contains the schema definition. > The second patch extends ynl to support netlink-raw > The third patch adds rtnetlink addr and route message types > > The second patch depends on "tools: ynl-gen: fix parse multi-attr enum > attribute": > > https://patchwork.kernel.org/project/netdevbpf/list/?series=769229 > > The netlink-raw schema is very similar to genetlink-legacy and I thought > about making the changes there and symlinking to it. On balance I > thought that might be problematic for accurate schema validation. > > rtnetlink doesn't seem to fit into unified or directional message > enumeration models. It seems like an 'explicit' model would be useful, > to require the schema author to specify the message ids directly. The > patch supports commands and it supports notifications, but it's > currently hard to support both simultaneously from the same netlink-raw > spec. I plan to work on this in a future patchset. > > There is not yet support for notifications because ynl currently doesn't > support defining 'event' properties on a 'do' operation. I plan to work > on this in a future patch. > > The link message types are a work in progress that I plan to submit in a > future patchset. Links contain different nested attributes dependent on > the type of link. Decoding these will need some kind of attr-space > selection based on the value of another attribute in the message. > > Donald Hunter (3): > doc/netlink: Add a schema for netlink-raw families > tools/net/ynl: Add support for netlink-raw families > doc/netlink: Add specs for addr and route rtnetlink message types Hi Donald, unfortunately this series doesn't apply to current net-next. Please consider rebasing and reposting.
On Wed, 26 Jul 2023 at 13:38, Simon Horman <simon.horman@corigine.com> wrote: > > On Tue, Jul 25, 2023 at 05:22:02PM +0100, Donald Hunter wrote: > > This patchset adds support for netlink-raw families such as rtnetlink. > > > > The first patch contains the schema definition. > > The second patch extends ynl to support netlink-raw > > The third patch adds rtnetlink addr and route message types > > > > The second patch depends on "tools: ynl-gen: fix parse multi-attr enum > > attribute": > > > > https://patchwork.kernel.org/project/netdevbpf/list/?series=769229 > > > > The netlink-raw schema is very similar to genetlink-legacy and I thought > > about making the changes there and symlinking to it. On balance I > > thought that might be problematic for accurate schema validation. > > > > rtnetlink doesn't seem to fit into unified or directional message > > enumeration models. It seems like an 'explicit' model would be useful, > > to require the schema author to specify the message ids directly. The > > patch supports commands and it supports notifications, but it's > > currently hard to support both simultaneously from the same netlink-raw > > spec. I plan to work on this in a future patchset. > > > > There is not yet support for notifications because ynl currently doesn't > > support defining 'event' properties on a 'do' operation. I plan to work > > on this in a future patch. > > > > The link message types are a work in progress that I plan to submit in a > > future patchset. Links contain different nested attributes dependent on > > the type of link. Decoding these will need some kind of attr-space > > selection based on the value of another attribute in the message. > > > > Donald Hunter (3): > > doc/netlink: Add a schema for netlink-raw families > > tools/net/ynl: Add support for netlink-raw families > > doc/netlink: Add specs for addr and route rtnetlink message types > > Hi Donald, > > unfortunately this series doesn't apply to current net-next. > Please consider rebasing and reposting. Hi Simon, As I mentioned in the cover letter, it depends on: "tools: ynl-gen: fix parse multi-attr enum attribute" https://patchwork.kernel.org/project/netdevbpf/list/?series=769229 Should I wait for that and repost? Thanks, Donald.
On Wed, Jul 26, 2023 at 02:06:02PM +0100, Donald Hunter wrote: > On Wed, 26 Jul 2023 at 13:38, Simon Horman <simon.horman@corigine.com> wrote: > > > > On Tue, Jul 25, 2023 at 05:22:02PM +0100, Donald Hunter wrote: > > > This patchset adds support for netlink-raw families such as rtnetlink. > > > > > > The first patch contains the schema definition. > > > The second patch extends ynl to support netlink-raw > > > The third patch adds rtnetlink addr and route message types > > > > > > The second patch depends on "tools: ynl-gen: fix parse multi-attr enum > > > attribute": > > > > > > https://patchwork.kernel.org/project/netdevbpf/list/?series=769229 > > > > > > The netlink-raw schema is very similar to genetlink-legacy and I thought > > > about making the changes there and symlinking to it. On balance I > > > thought that might be problematic for accurate schema validation. > > > > > > rtnetlink doesn't seem to fit into unified or directional message > > > enumeration models. It seems like an 'explicit' model would be useful, > > > to require the schema author to specify the message ids directly. The > > > patch supports commands and it supports notifications, but it's > > > currently hard to support both simultaneously from the same netlink-raw > > > spec. I plan to work on this in a future patchset. > > > > > > There is not yet support for notifications because ynl currently doesn't > > > support defining 'event' properties on a 'do' operation. I plan to work > > > on this in a future patch. > > > > > > The link message types are a work in progress that I plan to submit in a > > > future patchset. Links contain different nested attributes dependent on > > > the type of link. Decoding these will need some kind of attr-space > > > selection based on the value of another attribute in the message. > > > > > > Donald Hunter (3): > > > doc/netlink: Add a schema for netlink-raw families > > > tools/net/ynl: Add support for netlink-raw families > > > doc/netlink: Add specs for addr and route rtnetlink message types > > > > Hi Donald, > > > > unfortunately this series doesn't apply to current net-next. > > Please consider rebasing and reposting. > > Hi Simon, > > As I mentioned in the cover letter, it depends on: > "tools: ynl-gen: fix parse multi-attr enum attribute" > https://patchwork.kernel.org/project/netdevbpf/list/?series=769229 > > Should I wait for that and repost? Sorry my bad. I guess this is fine as-is unless Jakub says otherwise.
On Wed, 26 Jul 2023 15:16:11 +0200 Simon Horman wrote: > > As I mentioned in the cover letter, it depends on: > > "tools: ynl-gen: fix parse multi-attr enum attribute" > > https://patchwork.kernel.org/project/netdevbpf/list/?series=769229 > > > > Should I wait for that and repost? > > Sorry my bad. I guess this is fine as-is unless Jakub says otherwise. Right, just to be 100% clear, please don't repost, yet. I'll review it as is since it's of particular interest to me :) Simon is right that we don't accept patches which have yet-to-be-applied dependencies, tho.
On Wed, 26 Jul 2023 at 16:55, Jakub Kicinski <kuba@kernel.org> wrote: > > On Wed, 26 Jul 2023 15:16:11 +0200 Simon Horman wrote: > > > As I mentioned in the cover letter, it depends on: > > > "tools: ynl-gen: fix parse multi-attr enum attribute" > > > https://patchwork.kernel.org/project/netdevbpf/list/?series=769229 > > > > > > Should I wait for that and repost? > > > > Sorry my bad. I guess this is fine as-is unless Jakub says otherwise. > > Right, just to be 100% clear, please don't repost, yet. I'll review it > as is since it's of particular interest to me :) > Simon is right that we don't accept patches which have yet-to-be-applied > dependencies, tho. Ack, noted. Apologies for rushing it.