[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160223093139.21303e16@samsung9>
Date: Tue, 23 Feb 2016 09:31:39 -0800
From: Stephen Hemminger <stephen@...workplumber.org>
To: Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc: Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
davem@...emloft.net, idosch@...lanox.com, eladr@...lanox.com,
yotamg@...lanox.com, ogerlitz@...lanox.com, yishaih@...lanox.com,
dledford@...hat.com, sean.hefty@...el.com,
hal.rosenstock@...il.com, eugenia@...lanox.com,
roopa@...ulusnetworks.com, nikolay@...ulusnetworks.com,
hadarh@...lanox.com, jhs@...atatu.com, john.fastabend@...il.com,
jeffrey.t.kirsher@...el.com, brouer@...hat.com, ivecera@...hat.com,
rami.rosen@...el.com
Subject: Re: [patch net-next 3/9] mlx4: Implement port type setting via
devlink interface
On Tue, 23 Feb 2016 12:26:00 +0100
Hannes Frederic Sowa <hannes@...essinduktion.org> wrote:
> Hi Jiri,
>
> On 22.02.2016 19:31, Jiri Pirko wrote:
> > From: Jiri Pirko <jiri@...lanox.com>
> >
> > So far, there has been an mlx4-specific sysfs file allowing user to
> > change port type to either Ethernet of InfiniBand. This is very
> > inconvenient.
>
> Again, I want to express my concerns regarding all of this until this
> will be integrated into udev/systemd for stable device names. While one
> can build wrapper code around devlink to have stable devlink ports, I
> don't see a reason to include kernel code which actually has more
> problems than the sysfs approach. This harms admins to use those devices
> and will additionally require user space to write boiler plate code.
>
> Thanks,
> Hannes
>
I appreciate that you need to have a lighterweight model for
network devices. But have to agree with Hannes.
This code breaks the model expected by applications like Quagga, SNMP
and lots of other legacy code. Is this really going to work with the
legacy Linux model.
Powered by blists - more mailing lists