From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id A4F5C231E for ; Thu, 30 Aug 2018 00:42:04 +0200 (CEST) Received: by mail-wr1-f65.google.com with SMTP id j26-v6so6257463wre.2 for ; Wed, 29 Aug 2018 15:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Set7sIcpNGOn4vjBRY/G/dxxIdjZjPilcwkgOHazYKk=; b=Mm1819imvblUcnALpmXGlBkzvI7hMz7ArkSArD8/FYNAjo4uYNcuZf4XEZUbV8Dl9C 23Wmy0o7CIsQHsLkQjcNxEHEhxaLsc59x628aiIgHX/LkuS03orR8NHzy9saDZ2G7/rN hKfxK+MJLAjfd96FJ1HvQZdfAIJ8Dv3Sw9rE/8qtO1dzSIF/g/rmRUyF1DK5jRUEu/6F ed4TZcsy7yxz1BUJj3l4J0trH1ekYHTwTm9kQj8iPp8WOfRKdBvs6BlwCru4HGrbTMAi ynp3qFezNik0R6Ibw7KaDxcFN5kt7gm5cUNCCg2kQ72C3IbHaEp1UmMu3mG5R6b2mOf/ Gu/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Set7sIcpNGOn4vjBRY/G/dxxIdjZjPilcwkgOHazYKk=; b=AVST6THNAaQEEPWo7WHVKx3g9aByOxKj/5BP/+M08s2VvULuqrC5DRUm7EYyHFImQl Ww2wfM0cFit29/prkEQ1spCk7pEfiq3hGcndZES+TQevQeQxV18CB8PVotAHMaCyN+Gk +ceVJVGTIRZHvqw6wQSmwGVy+VIzKIgeF1eCV3Cbd+IV5Ts8KMhudbilGxOhbsRvPayP zzq/1mD7pUEkycm7r6EZQfBP/74+bixCK9/m8SNOL1dEhrleAQ4Y0YFRBkpC3kR66AcN lTDA57Um+UmKYOEFm8UV14olqfsygV4foJq6zzSZ3aF7roy+ADhnhp9fuLD/eVHFfDgM MZ1Q== X-Gm-Message-State: APzg51BO7vt1tkRbmvp3uDlNIQR2DvUmqlgyhE3m/f+Dt4X9kj6ABQjS a6N8SbB/u0U+JtYxTQ0ofnMX0vimSC9k0rytZ3c= X-Google-Smtp-Source: ANB0VdZf0MZtpER3qcHIIlI+9CK+cAZwRGgwIHW6ZIoGDiwL7LN4GGelKejY4gijLxMgxBn8aTx7vTnA9czHTUQcwwU= X-Received: by 2002:a5d:62c2:: with SMTP id o2-v6mr6049345wrv.83.1535582524167; Wed, 29 Aug 2018 15:42:04 -0700 (PDT) MIME-Version: 1.0 Sender: dan.gora@gmail.com Received: by 2002:adf:fbc1:0:0:0:0:0 with HTTP; Wed, 29 Aug 2018 15:41:23 -0700 (PDT) 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> From: Dan Gora Date: Wed, 29 Aug 2018 19:41:23 -0300 X-Google-Sender-Auth: roqwY8eDS3DjRDS9hBpelyepNms Message-ID: To: Stephen Hemminger Cc: Ferruh Yigit , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" 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 22:42:04 -0000 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.