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
