[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180409160348.12f8a6d9@xeon-e3>
Date: Mon, 9 Apr 2018 16:03:48 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: Siwei Liu <loseweigh@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, David Miller <davem@...emloft.net>,
David Ahern <dsahern@...il.com>, Jiri Pirko <jiri@...nulli.us>,
si-wei liu <si-wei.liu@...cle.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Alexander Duyck <alexander.h.duyck@...el.com>,
"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
Jakub Kicinski <kubakici@...pl>,
Jason Wang <jasowang@...hat.com>,
"Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
Netdev <netdev@...r.kernel.org>,
virtualization@...ts.linux-foundation.org,
virtio-dev@...ts.oasis-open.org
Subject: Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
On Mon, 9 Apr 2018 15:30:42 -0700
Siwei Liu <loseweigh@...il.com> wrote:
> On Mon, Apr 9, 2018 at 3:15 PM, Andrew Lunn <andrew@...n.ch> wrote:
> >> No, implementation wise I'd avoid changing the class on the fly. What
> >> I'm looking to is a means to add a secondary class or class aliasing
> >> mechanism for netdevs that allows mapping for a kernel device
> >> namespace (/class/net-kernel) to userspace (/class/net). Imagine
> >> creating symlinks between these two namespaces as an analogy. All
> >> userspace visible netdevs today will have both a kernel name and a
> >> userspace visible name, having one (/class/net) referecing the other
> >> (/class/net-kernel) in its own namespace. The newly introduced
> >> IFF_AUTO_MANAGED device will have a kernel name only
> >> (/class/net-kernel). As a result, the existing applications using
> >> /class/net don't break, while we're adding the kernel namespace that
> >> allows IFF_AUTO_MANAGED devices which will not be exposed to userspace
> >> at all.
> >
> > My gut feeling is this whole scheme will not fly. You really should be
> > talking to GregKH.
>
> Will do. Before spreading it out loudly I'd run it within netdev to
> clarify the need for why not exposing the lower netdevs is critical
> for cloud service providers in the face of introducing a new feature,
> and we are not hiding anything but exposing it in a way that don't
> break existing userspace applications while introducing feature is
> possible with the limitation of keeping old userspace still.
>
> >
> > Anyway, please remember that IFF_AUTO_MANAGED will need to be dynamic.
> > A device can start out as a normal device, and will change to being
> > automatic later, when the user on top of it probes.
>
> Sure. In whatever form it's still a netdev, and changing the namespace
> should be more dynamic than changing the class.
>
> Thanks a lot,
> -Siwei
>
> >
> > Andrew
Also, remember for netdev's /sys is really a third class API.
The primary API's are netlink and ioctl. Also why not use existing
network namespaces rather than inventing a new abstraction?
Powered by blists - more mailing lists