Messages in this thread | | | Date | Thu, 8 Jan 1998 22:36:10 +0100 | From | Martin von Loewis <> | Subject | Re: sysctl() considered harmful |
| |
> All arp_* have already disappeared.
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
| |