> > I'm sorry but the most of 2.1.77 NET_IPV4_* and NET_IPV6_* are obsolete.
> > So that just imagine, that they do not exist at all :-)
> > They will stabilize in 2.2 and, apparently, will have nothing
> > common with 2.0.
>
> Are you really saying those 52 NET_IPV4 calls are obsolete? In what
> sense? I see all of them implemented. For most of them, I see also
> code that depends on it...
All arp_* have already disappeared.
8 of device specific ip_* entries will disappear soon.
Also I'd move NET_IPV4_TCP_* entries (shared with IPv6) to a separate directory,
sort of "inet" to allow IPv6 without IPv4.
> You are essentially claiming that system management will not work in
> general, and that those people defining MIBs are wasting their time.
MIBs have nothing to do with sysctl interface.
Apparently, MIB implemetation backends must be updated when kernel change.
Is it not evident?
> Do you think this would solve the specific problem of breaking
> interfaces? If there would have been ioctls for all this IP
> configuration in 2.0, I doubt it would have survived in 2.2.
Well, until now no ioctls changed their semantics.
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)
Alas, we are not allowed to make it :-(
Working on it I lose 90% of time, trying not to break new logic,
at least to preserve its spirit, and still to allow its interpretation
in terms of BSD ioctls. Luckily, 2.0 had very poor semantics :-)
> As you say, if the mechanism changes, it is hard to keep the
> configuration of it - regardless what the interface to the
> configuration is.
>
> sysctl is solving the specific problem of a binary interface to
> system-global configuration data. Everything else proposed in place
> of it (parsing /proc, mis-using ioctl) is a hack compared to that.
I said, sysctl is not an API. At least string addresses exclude
possibility of occasional conflicts and dropping <linux/sysctl.h>
we would not lose anything, but code became only more clean.
To resume:
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?
Alexey