Thu, Mar 28, 2019 at 10:53:47AM CET, [email protected] wrote: >On Thu, Mar 28, 2019 at 10:21:26AM +0100, Jiri Pirko wrote: >> Wed, Mar 27, 2019 at 11:25:54PM CET, [email protected] wrote: >> > >> >I'm all for implementing new features which are are related to physical >> >device (ASIC) rather than network interface only in devlink (at the >> >level of kernel-userspace interface). But for features already provided >> >by ethtool (userspace utility) I can't help seeing the state of devlink >> >support in NIC drivers as a serious blocker. >> >> What I'm thinking about at for some time now would be en explicit >> default devlink and devlink_port registration for every netdev for >> drivers that does not support devlink themselves. I need to think about >> it more, but it seems doable. Then we can hang appropriate things there >> and make the ethtoolnl/devlink separation clear. I believe we need to do >> it. > >That sounds great, such "generic devlink" implementation would be a way >around. Kernel could then emulate features which are not implemented by >an actual devlink handler (i.e. "generic devlink" is used or particular >handler is missing) by falling back to ethtool_ops handler so that >userspace could rely on devlink API for things like device information, >various dumps, flashing etc. without losing anything.
Yep. Plan to do that next week. > >Michal
