lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 21 Jun 2018 14:19:55 +0200 From: Ivan Vecera <ivecera@...hat.com> To: Ilias Apalodimas <ilias.apalodimas@...aro.org>, Florian Fainelli <f.fainelli@...il.com> Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org, grygorii.strashko@...com, ivan.khoronzhuk@...aro.org, nsekhar@...com, jiri@...nulli.us, francois.ozog@...aro.org, yogeshs@...com, spatton@...com, Jose.Abreu@...opsys.com Subject: Re: [RFC v2, net-next, PATCH 4/4] net/cpsw_switchdev: add switchdev mode of operation on cpsw driver On 20.6.2018 20:03, Ilias Apalodimas wrote: > Hi Florian, > > On Wed, Jun 20, 2018 at 10:58:26AM -0700, Florian Fainelli wrote: >> On 06/20/2018 10:51 AM, Ilias Apalodimas wrote: >>> Hello Ivan, >>> On Wed, Jun 20, 2018 at 02:56:48PM +0200, Ivan Vecera wrote: >>>> On 18.6.2018 22:19, Ilias Apalodimas wrote: >>>>> Jiri proposed using devlink, which makes sense, but i am not sure it's >>>>> applicable on this patchset. This will change the driver completely and will >>>>> totally break backwards compatibility. >>>> >>>> Another good reason for a new driver. >>>> >>>> I. >>> This is actually conflicting at least to my understanding. Jiri proposed using >>> devlink was used as an alternative method to enable a new mode instead of >>> adding it on a .config option. A new driver wouldn't have a need for that right? >> >> Correct, with a new driver would likely behave correctly upon being >> probed such that you could have your switch ports act as normal network >> devices from which you could run IP-config and do NFS boot. > The current driver also does NFS properly and the 2 ethernet ports act as normal > network interfaces. The NFS section in the cover letter > is to cover the cases were users running on NFS need to change the running > switch configuration(starting from adding the 2 interfaces on a bridge). > Since iproute2 is located on the NFS filesystem the moment > network connectivity is lost, you loose the ability to perform further > configuration and in certian configuration scenarios render the device > unusable. Yes, with a new driver you can drop NFS-boot hack you mentioned in cover letter. All configuration is done during driver probe and thus prior NFS mount. Only thing you loose with a new driver is backward compatibility but the question is: DO you really need it? Ivan
Powered by blists - more mailing lists