All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Dan Gora <dg@adax.com>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>, dev@dpdk.org
Subject: Re: [PATCH v2 10/10] kni: add API to set link status on kernel interface
Date: Wed, 29 Aug 2018 16:10:43 -0700	[thread overview]
Message-ID: <20180829161043.11bb2434@xeon-e3> (raw)
In-Reply-To: <CAGyogRbBBAU92KdqVwghpon1brMo=4XJNPotiBYpztQkzB4mGQ@mail.gmail.com>

On Wed, 29 Aug 2018 19:41:23 -0300
Dan Gora <dg@adax.com> wrote:

> On Wed, Aug 29, 2018 at 7:12 PM, Dan Gora <dg@adax.com> wrote:
> > On Wed, Aug 29, 2018 at 7:00 PM, Stephen Hemminger
> > <stephen@networkplumber.org> 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 <dg@adax.com>  
> >>> >
> >>> > 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.
> 
> <snip>
> 
> - 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``)
> <snip>
> 
>     - kernel name (``sda``, ``tty``, ``0000:00:1f.2``, ...)
> <snip>
> 
>     - subsystem (``block``, ``tty``, ``pci``, ...)
> <snip>
> 
>     - driver (``tg3``, ``ata_piix``, ``uhci_hcd``)
> <snip>
> 
>     - attributes
> <snip>
> 
>     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.

  reply	other threads:[~2018-08-29 23:10 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28 22:45 [PATCH 00/10] kni: Interface detach and link status fixes Dan Gora
2018-06-29  1:54 ` Dan Gora
2018-06-29  1:54   ` [PATCH v2 01/10] kni: remove unused variables from struct kni_dev Dan Gora
2018-08-29 10:29     ` Ferruh Yigit
2018-06-29  1:55   ` [PATCH v2 02/10] kni: separate releasing netdev from freeing KNI interface Dan Gora
2018-08-29 10:59     ` Ferruh Yigit
2018-09-04  0:20       ` Dan Gora
2018-09-04  0:36       ` Dan Gora
2018-10-10 17:24         ` Ferruh Yigit
2018-10-10 18:18           ` Dan Gora
2018-10-10 22:51             ` Ferruh Yigit
2018-10-10 23:38               ` Dan Gora
2018-06-29  1:55   ` [PATCH v2 03/10] kni: don't touch struct kni_dev after freeing Dan Gora
2018-06-29  1:55   ` [PATCH v2 04/10] kni: add rte_kni_free to KNI library Dan Gora
2018-06-29  1:55   ` [PATCH v2 05/10] kni: don't run rte_kni_handle_request after interface release Dan Gora
2018-06-29  1:55   ` [PATCH v2 06/10] kni: increase length of timeout for KNI responses Dan Gora
2018-06-29  1:55   ` [PATCH v2 07/10] kni: update kni test for rte_kni_free Dan Gora
2018-06-29  1:55   ` [PATCH v2 08/10] kni: add rte_kni_free to KNI example app Dan Gora
2018-06-29  1:55   ` [PATCH v2 09/10] kni: add rte_kni_free to KNI vdev driver Dan Gora
2018-06-29  1:55   ` [PATCH v2 10/10] kni: add API to set link status on kernel interface Dan Gora
2018-08-29 11:48     ` Ferruh Yigit
2018-08-29 21:10       ` Dan Gora
2018-08-29 22:01         ` Stephen Hemminger
2018-08-29 15:54     ` Stephen Hemminger
2018-08-29 21:02       ` Dan Gora
2018-08-29 22:00         ` Stephen Hemminger
2018-08-29 22:12           ` Dan Gora
2018-08-29 22:41             ` Dan Gora
2018-08-29 23:10               ` Stephen Hemminger [this message]
2018-08-30  9:49                 ` Igor Ryzhov
2018-08-30 10:32                   ` Igor Ryzhov
2018-08-30 21:41                   ` Dan Gora
2018-08-30 22:09                     ` Stephen Hemminger
2018-08-30 22:11                       ` Dan Gora
2018-09-04  0:47                         ` Dan Gora
2018-09-05 12:57                           ` Stephen Hemminger
2018-09-11 21:45                             ` Dan Gora
2018-09-11 21:52                               ` Stephen Hemminger
2018-09-11 22:07                                 ` Dan Gora
2018-09-11 23:14                                   ` Stephen Hemminger
2018-09-12  4:02                                     ` Jason Wang
2018-09-11 23:14     ` [PATCH 0/2] " Dan Gora
2018-09-11 23:14     ` [PATCH 1/2] " Dan Gora
2018-09-11 23:18       ` Dan Gora
2018-07-20 11:36   ` [PATCH 00/10] kni: Interface detach and link status fixes Ferruh Yigit

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=20180829161043.11bb2434@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=dev@dpdk.org \
    --cc=dg@adax.com \
    --cc=ferruh.yigit@intel.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.