From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by dpdk.org (Postfix) with ESMTP id 560A0231E for ; Thu, 30 Aug 2018 01:10:47 +0200 (CEST) Received: by mail-pl1-f194.google.com with SMTP id d12-v6so2957727pls.4 for ; Wed, 29 Aug 2018 16:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=aaqLjAn1q+pCxCNrG+f5TjdBwX3qGzqYKoFez8HjXKc=; b=YBlQwTGrcLfft+um9/yzkCT+thPfUZOx7rYz94Ol2/7RH5MpHncJFyghEetXSkCtDW iVRoS5Sp49YP550QaN4hSTHisdn+agYcxGytXy7mavYP92KPWOmM9+YAmgRm9o+pq/ub 1pnZJS9kRJcXO/cQ3NstBIlBV0C9rKrrACYxsV4oo3an5nf421TCpsy8tia0kykGZExm Tk/mhuAUBkETnLLXc0HyVmJ/cuSLXJA9bhSUh85BAn4PGhGN992c7gM2KYgAGMxTnOvt yOoESIYpxdaIpu+smCXCTG9ySSLSG1daTj8UgZ6T7+azo7AbVu0IT5Hbqfnk1kkFaP+1 Tu8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=aaqLjAn1q+pCxCNrG+f5TjdBwX3qGzqYKoFez8HjXKc=; b=M4BQpA4LcPLINR18SckslCKLaLNrhD7YgIyw3EUARwIFa8kE2I5qt5osuftPawY3UC gsPgSd32a1azFUW2u0TVnH48vDqFRCkqTKZh5M6nFQWu2HBx+E841Bpa3+5muuiF8L/v +Abm9DGrH+wARDXL3OkbLrvyWvvlMCu8TeIcYw7utKUjsEankf+dGedB2is8T2o74FSs E2EIe3KlTDI6HZEJ7qar0Nf8WkXprF3cLinMS0s+diY7XtgUFadyjodHkkj4Hg5HWakG dUCfkfxguNPmFb9WaP5WxTeIUgiDiYMH+wiDRh3t+ssN5xD2cQMgudsCuq5M0b509p4v yleQ== X-Gm-Message-State: APzg51Db1YWv4hKiLHCx8f9mPR8ZvkdQUsknq2gX/jN2cdGSw2+lxVJQ 0ZwrJT78gEXWQfiPrkG6r3sETA== X-Google-Smtp-Source: ANB0VdYZ/4mcw3mPuGCMl3vKxbDeKqCII4cONtjV+/+eS/QLB67KhvxlLmtuneiKn3bwUh1YaA0QAQ== X-Received: by 2002:a17:902:900a:: with SMTP id a10-v6mr7659083plp.143.1535584246369; Wed, 29 Aug 2018 16:10:46 -0700 (PDT) Received: from xeon-e3 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id v7-v6sm7941633pgh.57.2018.08.29.16.10.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 Aug 2018 16:10:46 -0700 (PDT) Date: Wed, 29 Aug 2018 16:10:43 -0700 From: Stephen Hemminger To: Dan Gora Cc: Ferruh Yigit , dev@dpdk.org Message-ID: <20180829161043.11bb2434@xeon-e3> In-Reply-To: References: <20180628224513.18391-1-dg@adax.com> <20180629015508.26599-1-dg@adax.com> <20180629015508.26599-11-dg@adax.com> <20180829085410.4411c07e@xeon-e3> <20180829150014.0ae59128@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 10/10] kni: add API to set link status on kernel interface X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 23:10:47 -0000 On Wed, 29 Aug 2018 19:41:23 -0300 Dan Gora wrote: > On Wed, Aug 29, 2018 at 7:12 PM, Dan Gora wrote: > > On Wed, Aug 29, 2018 at 7:00 PM, Stephen Hemminger > > wrote: > >>> >> Add a new API function to KNI, rte_kni_update_link() to allow DPDK > >>> >> applications to update the link state for the KNI network interfaces > >>> >> in the linux kernel. > >>> >> > >>> >> Note that the default carrier state is set to off when the interface > >>> >> is opened. > >>> >> > >>> >> Signed-off-by: Dan Gora > >>> > > >>> > Do you really need a special ioctl for this? > >>> > There is already ability to set link state via sysfs or netlink. > >>> > >>> I think yes.. AFAIK sysfs does not constitute a stable API; > >> > >> It is a stable API on Linux. > > > > Actually this does not seem to be completely true... > > From Documentation/admin-guide/sysfs-rules.rst: > > Rules on how to access information in sysfs > =========================================== > > The kernel-exported sysfs exports internal kernel implementation details > and depends on internal kernel structures and layout. It is agreed upon > by the kernel developers that the Linux kernel does not provide a stable > internal API. Therefore, there are aspects of the sysfs interface that > may not be stable across kernel releases. > > > > - devices are only "devices" > There is no such thing like class-, bus-, physical devices, > interfaces, and such that you can rely on in userspace. Everything is > just simply a "device". Class-, bus-, physical, ... types are just > kernel implementation details which should not be expected by > applications that look for devices in sysfs. > > The properties of a device are: > > - devpath (``/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0``) > > > - kernel name (``sda``, ``tty``, ``0000:00:1f.2``, ...) > > > - subsystem (``block``, ``tty``, ``pci``, ...) > > > - driver (``tg3``, ``ata_piix``, ``uhci_hcd``) > > > - attributes > > > Everything else is just a kernel driver-core implementation detail > that should not be assumed to be stable across kernel releases. Network device sysfs is stable. No one ever got around to putting it in documentation I wouldn't worry, once anything in /sys/class/net is added it is not going to change without major breakage in many many tools.