From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D7E6C48BC2 for ; Sun, 27 Jun 2021 10:33:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2802661C31 for ; Sun, 27 Jun 2021 10:33:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230150AbhF0Kfl (ORCPT ); Sun, 27 Jun 2021 06:35:41 -0400 Received: from new3-smtp.messagingengine.com ([66.111.4.229]:35943 "EHLO new3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229761AbhF0Kfl (ORCPT ); Sun, 27 Jun 2021 06:35:41 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id E66605805C9; Sun, 27 Jun 2021 06:33:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 27 Jun 2021 06:33:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9Q9NxT OMyNZY04hi81t5aW1NL/jvGVXzK0xYeWpQ/yk=; b=Cnief0dEOZagOQc0SBNZe6 hM3dRqJl2eGWHaUqehQdBqeeWK/2b5/TbWAKV3rPGsjb+kj8FBbVNgxVGxJjdDU9 AbGw480/VbIR3DRkzmzygt4IzOcN/ZTkkpUnd40ln6fU5FKX14vCMkrQwHxKx6u9 4/QMHS+bMEjW94czVrQK+yywcRjKMDQ4LWf8PZBjnaX2J9GGwm1fRXqPMX++bOV8 zJNMPsfe3RCH5fhyV/zsMbNDl6HICtvj2qGu7+EAoITdhY+/JmAADm3RLnOZH4Lo JcIF5zLRBxMdmlQV2ZfqCKVkvn/Zob4rOe84pBIqQPLfW1oxoPKNtHJJLX3C2AXw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeehvddgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefkughoucfu tghhihhmmhgvlhcuoehiughoshgthhesihguohhstghhrdhorhhgqeenucggtffrrghtth gvrhhnpedtffekkeefudffveegueejffejhfetgfeuuefgvedtieehudeuueekhfduheel teenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehiug hoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 27 Jun 2021 06:33:15 -0400 (EDT) Date: Sun, 27 Jun 2021 13:33:13 +0300 From: Ido Schimmel To: Andrew Lunn Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org, jiri@nvidia.com, vladyslavt@nvidia.com, moshe@nvidia.com, vadimp@nvidia.com, mkubecek@suse.cz, mlxsw@nvidia.com, Ido Schimmel Subject: Re: [RFC PATCH net-next 0/4] ethtool: Add ability to write to transceiver module EEPROMs Message-ID: References: <20210623075925.2610908-1-idosch@idosch.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Jun 24, 2021 at 10:27:13PM +0200, Andrew Lunn wrote: > > I fail to understand this logic. I would understand pushing > > functionality into the kernel in order to create an abstraction for user > > space over different hardware interfaces from different vendors. This is > > not the case here. Nothing is vendor specific. Not to the host vendor > > nor to the module vendor. > > Hi Ido Hi Andrew, > > My worry is, we are opening up an ideal vector for user space drivers > for SFPs. And worse still, closed source user space drivers. We have > had great success with switchdev, over a hundred supported switches, > partially because we have always pushed back against kAPIs which allow > user space driver, closed binary blobs etc. I don't think it's a correct comparison. Switch ASICs don't have a standardized interface towards the host. It is therefore essential that the kernel will abstract these differences to user space. > > We have the choice here. We can add a write method to the kAPI, add > open source code to Ethtool using that API, and just accept people are > going to abuse the API for all sorts of horrible things in user space. > Or we can add more restrictive kAPIs, put more code in the kernel, and > probably limit user space doing horrible things. Maybe as a side > effect, SFP vendors contribute some open source code, rather than > binary blobs? I didn't see any code or binary blobs from SFP vendors and I'm not sure how they can provide these either. Their goal is - I believe - to sell as much modules as possible to what the standard calls "systems manufactures" / "system integrators". Therefore, they cannot make any assumptions about the I2C connectivity (whether to the ASIC or the CPU), the operating system running on the host and the user interface (ioctl / netlink etc). Given all these moving parts, I don't see how they can provide any tooling. It is in their best interest to simply follow the standard and make the tooling a problem of the "systems manufactures" / "system integrators". In fact, the user who requested this functionality claims: "the cable vendors don't develop the tools to burn the FW since the vendors claim that the CMIS is supported". The user also confirmed that another provider "is able to burn the FW for the cables from different vendors". > > I tend to disagree about adding kAPIs which allow write. But i would > like to hear other peoples opinions on this. > > Andrew >