[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190603143205.1d95818e@cakuba.netronome.com>
Date: Mon, 3 Jun 2019 14:32:05 -0700
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: <sameehj@...zon.com>
Cc: <davem@...emloft.net>, <netdev@...r.kernel.org>, <dwmw@...zon.com>,
<zorik@...zon.com>, <matua@...zon.com>, <saeedb@...zon.com>,
<msw@...zon.com>, <aliguori@...zon.com>, <nafea@...zon.com>,
<gtzalik@...zon.com>, <netanel@...zon.com>, <alisaidi@...zon.com>,
<benh@...zon.com>, <akiyano@...zon.com>
Subject: Re: [PATCH V2 net 00/11] Extending the ena driver to support new
features and enhance performance
On Mon, 3 Jun 2019 17:43:18 +0300, sameehj@...zon.com wrote:
> * net: ena: ethtool: add extra properties retrieval via get_priv_flags (2/11):
> * replaced snprintf with strlcpy
> * dropped confusing error message
> * added more details to the commit message
I asked you to clearly state that you are using the blindly passing
this info from the FW to user space. Stating that you "retrieve" it
is misleading.
IMHO it's a dangerous precedent, you're extending kernel's uAPI down to
the proprietary FW of the device. Now we have no idea what the flags
are, so we can't refactor and create common APIs among drivers, or even
use the same names. We have no idea what you're exposing.
Powered by blists - more mailing lists