All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Jiri Pirko <jiri@resnulli.us>
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	pablo@netfilter.org, Jamal Hadi Salim <jhs@mojatatu.com>,
	Jiri Benc <jbenc@redhat.com>,
	David Ahern <dsa@cumulusnetworks.com>
Subject: Re: [PATCH net-next v4 1/5] netlink: extended ACK reporting
Date: Tue, 11 Apr 2017 09:29:18 +0200	[thread overview]
Message-ID: <1491895758.31620.4.camel@sipsolutions.net> (raw)
In-Reply-To: <20170411071900.GC1976@nanopsycho> (sfid-20170411_091902_806901_2B2253F7)

On Tue, 2017-04-11 at 09:19 +0200, Jiri Pirko wrote:
> 
> > +	NUM_NLMSGERR_ATTRS,
> 
> According to the rest of the uapi, this should be rather named:
> 	__NLMSGERR_ATTR_MAX

nl80211 uses NUM_ so I guess that's a matter of convention, but I can
change that I guess.

> > 		if (err || (nlh->nlmsg_flags & NLM_F_ACK))
> > -			netlink_ack(skb, nlh, err);
> > +			netlink_ack(skb, nlh, err, NULL);
> 
> Wouldn't it make sense to leave netlink_ack as is and add
> netlink_ack_ext for those who need to pass non-null?

I thought about it, but didn't really see much point. The churn isn't
super big (a dozen callers or so), and I thought it makes sense to
point out to the users that there's something here.

johannes

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: Jiri Pirko <jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org>
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	pablo-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org,
	Jamal Hadi Salim <jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>,
	Jiri Benc <jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	David Ahern
	<dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
Subject: Re: [PATCH net-next v4 1/5] netlink: extended ACK reporting
Date: Tue, 11 Apr 2017 09:29:18 +0200	[thread overview]
Message-ID: <1491895758.31620.4.camel@sipsolutions.net> (raw)
In-Reply-To: <20170411071900.GC1976@nanopsycho> (sfid-20170411_091902_806901_2B2253F7)

On Tue, 2017-04-11 at 09:19 +0200, Jiri Pirko wrote:
> 
> > +	NUM_NLMSGERR_ATTRS,
> 
> According to the rest of the uapi, this should be rather named:
> 	__NLMSGERR_ATTR_MAX

nl80211 uses NUM_ so I guess that's a matter of convention, but I can
change that I guess.

> > 		if (err || (nlh->nlmsg_flags & NLM_F_ACK))
> > -			netlink_ack(skb, nlh, err);
> > +			netlink_ack(skb, nlh, err, NULL);
> 
> Wouldn't it make sense to leave netlink_ack as is and add
> netlink_ack_ext for those who need to pass non-null?

I thought about it, but didn't really see much point. The churn isn't
super big (a dozen callers or so), and I thought it makes sense to
point out to the users that there's something here.

johannes

  reply	other threads:[~2017-04-11  7:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11  6:56 [PATCH net-next v4 0/5] netlink extended ACK reporting Johannes Berg
2017-04-11  6:56 ` [PATCH net-next v4 1/5] netlink: " Johannes Berg
2017-04-11  7:08   ` Jiri Pirko
2017-04-11  7:19   ` Jiri Pirko
2017-04-11  7:19     ` Jiri Pirko
2017-04-11  7:29     ` Johannes Berg [this message]
2017-04-11  7:29       ` Johannes Berg
2017-04-11  8:13       ` Jiri Pirko
2017-04-11  8:29         ` Johannes Berg
2017-04-11  8:57           ` Jiri Pirko
2017-04-11  8:57             ` Jiri Pirko
2017-04-11  6:56 ` [PATCH net-next v4 2/5] genetlink: pass extended ACK report down Johannes Berg
2017-04-11  6:56 ` [PATCH net-next v4 3/5] netlink: allow sending extended ACK with cookie on success Johannes Berg
2017-04-11  6:56 ` [PATCH net-next v4 4/5] netlink: pass extended ACK struct to parsing functions Johannes Berg
2017-04-11  6:56   ` Johannes Berg
2017-04-11  6:57 ` [PATCH net-next v4 5/5] netlink: pass extended ACK struct where available Johannes Berg

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=1491895758.31620.4.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=dsa@cumulusnetworks.com \
    --cc=jbenc@redhat.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /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.