Looking at 2.1.78, I see that
sysctl_arp_timeout
sysctl_arp_max_tries
sysctl_arp_res_time
sysctl_arp_confirm_interval
sysctl_arp_max_pings
sysctl_arp_dead_res_time
are still used in net/ipv4/arp.c.
> 8 of device specific ip_* entries will disappear soon.
When you say 'they 'll disappear', you mean of course that the
values of the sysctls will be still available, right? It's only
the underlying implementation that will be removed, so that
sysctl will return ENO
> MIBs have nothing to do with sysctl interface.
> Apparently, MIB implemetation backends must be updated when kernel change.
> Is it not evident?
Yes, the evidence is that the code evaluating sysctl variables should
change, so that the semantics of the variable is preserved, while the
mechanism changing the variable might be completely redone.
If this is not possible at all, you selected the wrong variables to
expose. If you think you have to drop them, ok. NEVER introduce
a new variable under an old name, though.
> Well, until now no ioctls changed their semantics.
Which, you hopefully agree, is a good thing.
> I object against strict binding sysctl values exactly because
> I really know how it is difficult to formulate new concepts
> in old terms. Look at emulation IPv4 SIOC[SG]IF* and
> SIOC{ADD,DEL}RT (brr...) and count how much code we could save if we could
> drop them. (Really, taking into account indirect influence, the redundant code
> is much larger: all the logic is distorted)
I don't object dropping sysctl variables. If you cannot longer support
them, drop them. If you think you need to expose new variables, expose
them. PLEASE don't expose new variables under old names. This is exactly
what Andries Brouwer complained about, and rightly so.
> The only alternative that I see is to remove almost all currently
> existing sysctl entries and reregister only those passing tests
> on implementation independance.
>
> Do you propose it?
Essentially, yes. When it comes to the networking sysctls, I don't
really care which ones you have and which ones you don't. When I use
sysctl, I control different things (like ntfs features :-).
My point is that you should recycle sysctl values under no
circumstances. I also believe that sysctl(2) is a good thing, and
should be maintained if possible. In that sense, it is official API -
although there are only limited guarantees as to compatibility between
kernel versions.
Regards,
Martin