On Tue, Dec 1, 2015, at 21:57, David Miller wrote: > From: Stephen Hemminger <step...@networkplumber.org> > Date: Tue, 1 Dec 2015 12:20:38 -0800 > > > On Tue, 01 Dec 2015 14:28:47 -0500 (EST) > > David Miller <da...@davemloft.net> wrote: > > > >> From: Stephen Hemminger <step...@networkplumber.org> > >> Date: Tue, 1 Dec 2015 08:06:52 -0800 > >> > >> > On Tue, 01 Dec 2015 17:02:23 +0100 > >> > Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > >> > > >> >> On Tue, Dec 1, 2015, at 16:50, Maximilian Wilhelm wrote: > >> >> > > I'm not sure I understand how this would work- are we going to > >> >> > > pin down the ifindex for some subset of interfaces? > >> >> > > >> >> > I'm not sure what your idea is, but I guess we might mean the same > >> >> > thing: > >> >> > > >> >> > What I have in mind is that the user can supply a list of (ifname -> > >> >> > ifindex) entries via a sysfs/procfs interface and if such a list is > >> >> > present, the kernel will search the list for every ifname which is > >> >> > registered and check if there is an entry. If there is, the ifindex > >> >> > for this entry is used. If there is no entry found for the given > >> >> > ifname, the usual algorithm is used (therefore inherently providing > >> >> > backward compatibility). > >> >> > >> >> Sorry to ask because I don't like this feature at all. There was a lot > >> >> of work on stable interface names. Why do you need stable ifindexes, > >> >> which were never meant to be stable for a longer amount of time? > >> > > >> > Also current versions of SNMP provide more useful information about > >> > network interface slot information in ifDescription > >> > >> Well if they do provide strings, then that is probably a better way > >> forward than messing with the kernel. > > > > It gives strings based on PCI information but nothing useful > > on tunnels. > > But at least in theory, that could be extended to do so right?
I had several snmp installations with net-snmp and munin, cacti and so on and all had the interface name in ifDescription already some years back. -- 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
