On 26/08/15 11:21, Scott Feldman wrote: > On Wed, Aug 26, 2015 at 10:49 AM, David Miller <da...@davemloft.net> wrote: >> From: Jiri Pirko <j...@resnulli.us> >> Date: Wed, 26 Aug 2015 09:37:57 +0200 >> >>> I don't think that are much more cases like this. Therefore I think that >>> for this cases, debugfs might be a good way to expose debugging stats. >> >> Scott wanted to do similar things in rocker. DSA guys too. >> >> Every switch device is going to have some kind of hierarchy like >> this, it's not a unique situation. > > We've been able to get buy so far without a user-visible device for > the switch. The switch ports are represented by netdevs, so that's > easy. How can we create an object for the switch itself, so we can > attach common interfaces for the user to dump switch-level stats or > tables? Using another netdev doesn't seem right. Do we need a new > device class for switches, and then create some common tool/interfaces > for switch device class?
I agree this is something crucially missing. If we try to list what could be missing currently, there is mostly: * switch-wide statistics, tables, databases * controlling a firmware agent running on the switch * restarting/re-configuring the switch hardware All of these already have proper ethtool control interfaces, so using something that understands a specialized net_device might be the easiest way to go, but we would need a way to put it in the non network device name space so tools and users to do not get confused? We could also have a specific SET_NETDEV_DEVTYPE() which helps make that specific device be part of a "switch-mgmt" class for instance? -- Florian -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
