On Fri, Sep 13, 2013 at 09:53:03AM +0200, Martin Pieuchot wrote: > > -let snmpd (or sth else) make up ifindices just for that purpose > > That looks like the best solution to me. If a userland program want > to expose following numbers, then it probably needs to create its own > indexes anyway, even our actual in-kernel code doesn't guarantee that. >
No, that's utterly stupid. The interface index is a value that is supposed to be consistent across the system. How should it be synced with other userland tools? How would you handle it in if_nametoindex and friends? As I said before: it is not a big issue for snmpd and I can live with the fact that your changes might confuse SNMP clients a bit. Just go ahead, but > In the end we need two different tables, one with an unique index per > interface (to avoid passing pointers in kernel) and another one with > the biggest index equals to the number of interfaces (to not confuse > snmp). IMHO we don't need these two tables in the kernel. > please read the history: if_index _was_ created for SNMP. Then it was used for routing and other stuff. Now you want to use it as a "PID" for something else. Fine. But please stop claiming that SNMP is doing anything wrong with if_indexes when they were created FOR SNMP. Reyk
