Am 12.12.2013 22:47, schrieb John Fastabend: > [...] > >>> Just to elaborate... >>> >>> Any application using lldp information will want to get events when >>> TLVs change. Maybe you can contrive ethtool to do this but its >>> going to >>> be ugly. Netlink can support multicast events and applications can >>> register for them. Also netlink's TLV format matches nicely with >>> LLDPs >>> TLV format. >> >> ethtool and netlink usually intersect for a few bits of information >> such as link status for instance. It is useful to have this >> information twice, with ethtool as a debugging aid, and via >> netlink to >> take appropriate actions. >> >> Maybe we just need to be clear on what needs to be present in ethtool >> only (configuration, static information) and see on a case-by-case >> what needs to be present in both ethtool and netlink? >> > > OK if there is an enable/disable bit in ethtool that might make some > sense. Or an error flag that is helpful to have. > > In this case we are dealing with peer attributes which are dynamic and > in my opinion should go into netlink and duplicating them in ethtool > although possible doesn't seem very useful to me. I think what most folks in the discussion so far assume is that we have a full LLDP implementation with respective hooks and events. This is not true for our device: We can only poll it for the adjacent link port's state, and that's it. I.e. we don't receive any events for changes on the port's state. lldpad seems to handle the entire LLDP layer in software. And I'm not sure if our device integrates with that so well, as it handles LLDP on its own. We'd have to disable pretty much all functionality that lldpad offers, and limit support to display of a few parameters which we would have to poll on demand. Likewise with netlink: If one of the arguments for netlink is that it supports notifications, then we can't take any advantage of that either, for the reasons stated above. By its nature, what we can offer and support with our device is simple debugging functionality, displaying the current state of the switch port at a given moment - just like ethtool will display the current port speed and media type. Hence the original idea to add respective functionality to ethtool in a generic manner, so others with similar constraints could use it as well. If ethtool is not acceptable, and if lldpad and netlink are no good fits either, would respective sysfs attributes for our device type work? Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
