From: Stephen Hemminger <stephen@networkplumber.org>
To: Serhey Popovych <serhe.popovych@gmail.com>
Cc: David Ahern <dsahern@gmail.com>, netdev@vger.kernel.org
Subject: Re: [PATCH iproute2-next v3 8/8] iplink: Reduce number of arguments to iplink_parse()
Date: Mon, 26 Feb 2018 13:35:56 -0800 [thread overview]
Message-ID: <20180226133556.1e24b6d1@xeon-e3> (raw)
In-Reply-To: <a57a5871-86d6-0988-ad5b-cc57d9cf1f76@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2749 bytes --]
On Mon, 26 Feb 2018 22:09:03 +0200
Serhey Popovych <serhe.popovych@gmail.com> wrote:
> Serhey Popovych wrote:
> > David Ahern wrote:
> >> On 2/26/18 11:20 AM, Serhey Popovych wrote:
> >>> Stephen Hemminger wrote:
> >>>> On Thu, 22 Feb 2018 15:02:06 +0200
> >>>> Serhey Popovych <serhe.popovych@gmail.com> wrote:
> >>>>
> >>>>> +struct iplink_parse_args {
> >>>>> + const char *dev;
> >>>>> + const char *name;
> >>>>> + const char *type;
> >>>>> +
> >>>>> + /* This definitely must be the last one and initialized
> >>>>> + * by the caller of iplink_parse() that will initialize rest.
> >>>>> + */
> >>>>> + struct iplink_req *req;
> >>>>> +};
> >>>>> +
> >>>>
> >>>> No control block please.
> >>> Accepted.
> >>>
> >>>> If you have too many arguments, then that means you need to do
> >>>> some refactoring.
> >>>
> >>> So using structure as single argument to a function isn't an option?
> >>>
> >>>>
> >>>
> >>>
> >>
> >> As I mentioned before, iplink_parse should not be used by vxcan or veth
> >> as they only want a subset of the parsing. Once you take those users
> >> out, iplink_parse becomes local to iplink.c with a single user. In which
> >> case I suspect the compiler will always inline the function so no
> >> refactoring on the number of arguments is needed.
> >>
> > I will implement cut down function to parse vxcan and veth peer device
> > parameters and reuse it in iplink_parse() to avoid code duplications.
> >
> > But my final goal not to refactor on number of arguments to parse,
> > that's side product of this series, I want to take @name, @dev and
> > other parameters for later use. In ->parse_opt() modules @name, @dev
> > and others are not available easily. It seems only way to get them is
> > to parse supplied netlink buffer.
> >
> >
> While looking on how to make iplink_parse_light() that will be used with
> vxcan and veth I found following problems:
>
> 1) need to copy nearly all parameters parsing code (except vf, alias,
> carrier, master, protodown, link-netnsid, addrgenmode). this will
> be mitigated by re using iplink_parse_light() in iplink_parse()
>
> 2) how to add attributes like IFLA_GROUP? in caller? this will give
> even more code duplications.
>
> 3) there is high risk of adding regression either via conflicting
> matches() parameter in userspace or missing kernel attribute
> previously supported.
>
> Sorry, I do not like this approach. I do not want to broke anything,
> I just want @name and @dev parameters in ->parse_opt().
>
>
> 2)
> >
If the work to use common code is bigger than the code itself
then why bother. There is no benefit.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2018-02-26 21:36 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-22 13:01 [PATCH iproute2-next v3 0/8] iplink: Improve iplink_parse() Serhey Popovych
2018-02-22 13:01 ` [PATCH iproute2-next v3 1/8] utils: Introduce and use nodev() helper routine Serhey Popovych
2018-02-22 13:02 ` [PATCH iproute2-next v3 2/8] iplink: Correctly report error when network device isn't found Serhey Popovych
2018-02-23 23:41 ` David Ahern
2018-02-25 12:07 ` Serhey Popovych
2018-02-22 13:02 ` [PATCH iproute2-next v3 3/8] iplink: Use "dev" and "name" parameters interchangeable when possible Serhey Popovych
2018-02-22 13:02 ` [PATCH iproute2-next v3 4/8] iplink: Follow documented behaviour when "index" is given Serhey Popovych
2018-02-22 13:02 ` [PATCH iproute2-next v3 5/8] veth,vxcan: Save/reinitialize/restore whole @struct ifinfomsg Serhey Popovych
2018-02-26 3:28 ` David Ahern
2018-02-26 15:48 ` Serhey Popovych
2018-02-26 15:57 ` Serhey Popovych
2018-02-22 13:02 ` [PATCH iproute2-next v3 6/8] iplink: Perform most of request buffer setups and checks in iplink_parse() Serhey Popovych
2018-02-26 3:31 ` David Ahern
2018-02-26 15:51 ` Serhey Popovych
2018-02-22 13:02 ` [PATCH iproute2-next v3 7/8] iplink: Move data structures to block of their users Serhey Popovych
2018-02-22 13:02 ` [PATCH iproute2-next v3 8/8] iplink: Reduce number of arguments to iplink_parse() Serhey Popovych
2018-02-26 3:35 ` David Ahern
2018-02-26 15:44 ` Serhey Popovych
2018-02-26 16:07 ` Serhey Popovych
2018-02-26 18:06 ` Stephen Hemminger
2018-02-26 18:20 ` Serhey Popovych
2018-02-26 18:27 ` David Ahern
2018-02-26 18:38 ` Serhey Popovych
2018-02-26 20:09 ` Serhey Popovych
2018-02-26 21:35 ` Stephen Hemminger [this message]
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=20180226133556.1e24b6d1@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=dsahern@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=serhe.popovych@gmail.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.