All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hangbin Liu <liuhangbin@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, Jiri Pirko <jiri@resnulli.us>,
	Paolo Abeni <pabeni@redhat.com>
Subject: Re: [Draft PATCH net-next 0/3] add YAML spec for team
Date: Thu, 14 Dec 2023 12:15:07 +0800	[thread overview]
Message-ID: <ZXqBSyBt7xiv7YyA@Laptop-X1> (raw)
In-Reply-To: <20231213083642.1872702f@kernel.org>

Hi Jakub,
On Wed, Dec 13, 2023 at 08:36:42AM -0800, Jakub Kicinski wrote:
> > There are still some questions I got during convertion.
> > 
> > 1. Is there a preference to use "-" instead of "_" for the names in spec file?
> >    e.g. the attr-cnt-name in team.spec, should I use __team-attr-item-port-max
> >    or --team-attr-item-port-max, or __team_attr_item_port_max?
> 
> Minor preference for using -, but it mostly matters for things which
> will be visible outside of C. For instance in attr names when they are
> used in python: 
>   msg['port-index']
> looks nicer to me than
>   msg['port_index']
> and is marginally easier to type. But cnt-name is a C thing, so up to
> you. If I was writing it myself I'd probably go with
> --team-attr-item-port-max, that's what MPTCP did.

Thanks, I will do as what else do

> 
> > 2. I saw ynl-gen-c.py deals with unterminated-ok. But this policy is not shown
> >    in the schemas. Is it a new feature that still working on?
> 
> I must have added it to the code gen when experimenting with a family 
> I didn't end up supporting. I'm not actively working on that one, feel
> free to take a stab at finishing it or LMK if you need help.

OK, I will do it.

> 
> > 3. Do we have to hard code the string max-len? Is there a way to use
> >    the name in definitions? e.g.
> >    name: name
> >    type: string
> >    checks:
> >      max-len: string-max-len
> 
> Yes, that's the intention, if codegen doesn't support that today it
> should be improved.

I can try improve this. But may a little late (should go next year).
If you have time you can improve this directly.

> 
> > 4. The doc will be generate to rst file in future, so there will not have
> >    other comments in the _nl.c or _nl.h files, right?
> 
> It already generates ReST:
> https://docs.kernel.org/next/networking/netlink_spec/
> We do still generate kdoc in the uAPI header, tho.

How to generate the doc in uAPI header?

> 
> > 5. the genl_multicast_group is forced to use list. But the team use format
> >    like { .name = TEAM_GENL_CHANGE_EVENT_MC_GRP_NAME, }. Should we support
> >    this legacy format?
> 
> Do you mean that we generate:
> 
> 	[ID] = { "name", }
> 
> rather than:
> 
> 	[ID] = { .name = "name", }
> 
> ? I think the struct had only one member at the time, so I didn't
> bother adding the .name, but you can change the code-gen.

No, the current team just do like

static const struct genl_multicast_group team_nl_mcgrps[] = {
        { .name = TEAM_GENL_CHANGE_EVENT_MC_GRP_NAME, },
};

So there is new ID was defined. Looks the group id is not a must.

> > 7. When build, I got error modpost: missing MODULE_LICENSE() in drivers/net/team/team_nl.o.
> >    Should we add the MODULE_LICENSE support in ynl-gen-c.py?
> 
> Not sure if we can, the generated code should be linked with 
> the implementation to form a full module. The manually written
> part of the implementation should define the license. YAML specs
> have a fairly odd / broadly open license because they are uAPI.
> We don't want to start getting into licensing business.
> 
> > 8. When build, I also got errors like
> >      ERROR: modpost: "team_nl_policy" [drivers/net/team/team.ko] undefined!
> >      ERROR: modpost: "team_nl_ops" [drivers/net/team/team.ko] undefined!
> >      ERROR: modpost: "team_nl_noop_doit" [drivers/net/team/team_nl.ko] undefined!
> >      ERROR: modpost: "team_nl_options_set_doit" [drivers/net/team/team_nl.ko] undefined!
> >      ERROR: modpost: "team_nl_options_get_doit" [drivers/net/team/team_nl.ko] undefined!
> >      ERROR: modpost: "team_nl_port_list_get_doit" [drivers/net/team/team_nl.ko] undefined!
> >      ERROR: modpost: "team_attr_option_nl_policy" [drivers/net/team/team.ko] undefined!
> >   Do you know why include "team_nl.h" doesn't help?
> 
> Same reason as the reason you're getting the LICENSE warning.
> kbuild is probably trying to build team_nl and team as separate modules.
> 
> I think you'll have to rename team.c, take a look at what I did around
> commit 08d323234d10. I don't know a better way...

Thanks, this works for me.

Cheers
Hangbin

  reply	other threads:[~2023-12-14  4:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13  8:44 [Draft PATCH net-next 0/3] add YAML spec for team Hangbin Liu
2023-12-13  8:45 ` [Draft PATCH net-next 1/3] Documentation: netlink: add a " Hangbin Liu
2023-12-13 15:36   ` Jiri Pirko
2023-12-14  3:44     ` Hangbin Liu
2023-12-14  8:25       ` Jiri Pirko
2023-12-13 16:18   ` Jakub Kicinski
2023-12-14  3:52     ` Hangbin Liu
2023-12-14 19:14       ` Jakub Kicinski
2023-12-13  8:45 ` [Draft PATCH net-next 2/3] net: team: use policy generated by YAML spec Hangbin Liu
2023-12-13 15:44   ` Jiri Pirko
2023-12-13  8:45 ` [Draft PATCH net-next 3/3] uapi: team: use header file generated from " Hangbin Liu
2023-12-13 15:39   ` Jiri Pirko
2023-12-13 16:36 ` [Draft PATCH net-next 0/3] add YAML spec for team Jakub Kicinski
2023-12-14  4:15   ` Hangbin Liu [this message]
2023-12-14 19:17     ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZXqBSyBt7xiv7YyA@Laptop-X1 \
    --to=liuhangbin@gmail.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.