All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Nguyen <anthony.l.nguyen@intel.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Jiri Slaby <jirislaby@kernel.org>,
	"Loktionov, Aleksandr" <aleksandr.loktionov@intel.com>,
	Jan Sokolowski <jan.sokolowski@intel.com>,
	<jesse.brandeburg@intel.com>, <linux-kernel@vger.kernel.org>,
	Martin Liska <mliska@suse.cz>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	<intel-wired-lan@lists.osuosl.org>, <netdev@vger.kernel.org>
Subject: Re: [PATCH] i40e (gcc13): synchronize allocate/free functions return type & values
Date: Fri, 4 Nov 2022 13:28:44 -0700	[thread overview]
Message-ID: <eb9c26db-d265-33c1-5c25-daf9f06f91d4@intel.com> (raw)
In-Reply-To: <20221104114730.42294e1c@kernel.org>



On 11/4/2022 11:47 AM, Jakub Kicinski wrote:
> On Fri, 4 Nov 2022 11:33:07 -0700 Tony Nguyen wrote:
>> As Jiri mentioned, this is propagated up throughout the driver. We could
>> change this function to return int but all the callers would then need
>> to convert these errors to i40e_status to propagate. This doesn't really
>> gain much other than having this function return int. To adjust the
>> entire call chain is going to take more work. As this is resolving a
>> valid warning and returning what is currently expected, what are your
>> thoughts on taking this now to resolve the issue and our i40e team will
>> take the work on to convert the functions to use the standard errnos?
> 
> My thoughts on your OS abstraction layers should be pretty evident.
> If anything I'd like to be more vigilant about less flagrant cases.
> 
> I don't think this is particularly difficult, let's patch it up
> best we can without letting the "status" usage grow.

Ok thanks will do.

WARNING: multiple messages have this Message-ID (diff)
From: Tony Nguyen <anthony.l.nguyen@intel.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Jiri Slaby <jirislaby@kernel.org>,
	linux-kernel@vger.kernel.org, "Loktionov,
	Aleksandr" <aleksandr.loktionov@intel.com>,
	Eric Dumazet <edumazet@google.com>,
	intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	Paolo Abeni <pabeni@redhat.com>, Martin Liska <mliska@suse.cz>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Intel-wired-lan] [PATCH] i40e (gcc13): synchronize allocate/free functions return type & values
Date: Fri, 4 Nov 2022 13:28:44 -0700	[thread overview]
Message-ID: <eb9c26db-d265-33c1-5c25-daf9f06f91d4@intel.com> (raw)
In-Reply-To: <20221104114730.42294e1c@kernel.org>



On 11/4/2022 11:47 AM, Jakub Kicinski wrote:
> On Fri, 4 Nov 2022 11:33:07 -0700 Tony Nguyen wrote:
>> As Jiri mentioned, this is propagated up throughout the driver. We could
>> change this function to return int but all the callers would then need
>> to convert these errors to i40e_status to propagate. This doesn't really
>> gain much other than having this function return int. To adjust the
>> entire call chain is going to take more work. As this is resolving a
>> valid warning and returning what is currently expected, what are your
>> thoughts on taking this now to resolve the issue and our i40e team will
>> take the work on to convert the functions to use the standard errnos?
> 
> My thoughts on your OS abstraction layers should be pretty evident.
> If anything I'd like to be more vigilant about less flagrant cases.
> 
> I don't think this is particularly difficult, let's patch it up
> best we can without letting the "status" usage grow.

Ok thanks will do.
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  reply	other threads:[~2022-11-04 20:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-31 11:44 [PATCH] i40e (gcc13): synchronize allocate/free functions return type & values Jiri Slaby (SUSE)
2022-10-31 11:44 ` [Intel-wired-lan] " Jiri Slaby (SUSE)
2022-11-03  3:41 ` Jakub Kicinski
2022-11-03  3:41   ` [Intel-wired-lan] " Jakub Kicinski
2022-11-03 12:03   ` Jiri Slaby
2022-11-03 12:03     ` [Intel-wired-lan] " Jiri Slaby
2022-11-04 18:33     ` Tony Nguyen
2022-11-04 18:33       ` [Intel-wired-lan] " Tony Nguyen
2022-11-04 18:47       ` Jakub Kicinski
2022-11-04 18:47         ` [Intel-wired-lan] " Jakub Kicinski
2022-11-04 20:28         ` Tony Nguyen [this message]
2022-11-04 20:28           ` Tony Nguyen
2022-12-12 11:55           ` Jiri Slaby
2022-12-12 11:55             ` [Intel-wired-lan] " Jiri Slaby
2022-12-12 17:51             ` Tony Nguyen
2022-12-12 17:51               ` [Intel-wired-lan] " Tony Nguyen

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=eb9c26db-d265-33c1-5c25-daf9f06f91d4@intel.com \
    --to=anthony.l.nguyen@intel.com \
    --cc=aleksandr.loktionov@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jan.sokolowski@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=jirislaby@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mliska@suse.cz \
    --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.