On 12/09/13(Thu) 18:56, Henning Brauer wrote: > * Mike Belopuhov <m...@belopuhov.com> [2013-09-12 17:54]: > > it makes no sense whatsoever, reyk. those indices can be easily > > stolen and nobody guarantees that if you create vlan10, vlan11, > > then destroy vlan10, create vlan12 and vlan10 that vlan10 will > > have the same index as before. in fact it might be a different > > interface created for a different purpose days after. who knows? > > if snmp client relies on this behavior, it's broken since we have > > never made any provisions regarding how we use those indices. > > correct. > > however, it is not reyk who's on drugs here, it's snmp itself. using > the OS-private ifindex and making assumptions about it is the root > problem. but since that's in the standards, there are only 2 possible > solutions I see: > -keep trying to please snmp in the way we assign ifindex
That would involve modifying the actual code to not reuse the *last* but *first* free index ;) But it doesn't help at all for our problem, which means that we need another API to not pass pointers to interfaces in our kernel. > -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. 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. Martin
