Agreed. Backwards compatibility in this kind of way is evil (though a
necessary evil sometimes).
> A good adaptable interface doesn't need backwards compatitbility,
> as is the case of tagged entries. The backwards compatibility
> in this case comes from the flexibility of a fixed interface rather
> than playing with different interfaces and having to know which one
> it is.
It's worth realising that the reason /proc hasn't bitten us too badly
is because not very much uses it yet -- only a couple of utility
packages that are easy to download. This may not last, especially
since we're exporting more and more of the system's interface this
way.
> Also, "when kernel changes affect a large enough user base, some means
> of backwards compatibility must be maintained" is not a simple policy
> to implement. It generally difficult to maintain and ends up falling
> under my second objection to "backward compatibility".
If something is broken in linux, we should fix it. The only
compatibility we should be worrying too much about is things that
affect *portability* -- not linux-specific hacks. *Application*
portability and stability is important, little system utilities less
so.
What we *should* be doing is giving rather more advance warning that
something's going to change incompatibly, and letting the utility
developers know well in advance.
Part of the problem, of course, is that in terms of *stable releases*
users *do* get plenty of warning. However everyone insists on running
the latest dodgy development kernel, and *then* complaining about its
instability and incompatibility. Maybe there ought to be stronger
warnings about running development kernels in production environments,
similar to the way the FreeBSD folks do it?
wrt the suggestions about moving /proc because ours isn't compatible
with someone elses: is there any standard for the way /proc should
work? I don't think so from what I've seen. Is solaris' /proc
compatible with freebsd's /proc or anyotherrandomunix's /proc?
[I just checked; solaris works different from freebsd which works
differently than linux]
*IF* there's a definite standard for the way the thing should work,
and it matters for application portability (the latter is IMHO
doubtful; /proc on solaris et al is just a safer way of doing what
used to be done with KVM routines, and is therefore limited to things
like system utilities, debuggers etc) *THEN* we should maybe change.
I don't think it's needed.
I *do* think the structure of the non-process things in /proc needs to
be rethought, though; it's completely random and ad-hoc. Ideally,
every driver, every component of the system ought to have /proc
entries, and every system parameter that's sensible should be readable
and writable through /proc. They should be arranged in a sensible
directory structure and with a common format.
The easiest way to have this common format is to provide a set of
routines in the kernel to do it; this way, it's *easier* to provide a
compliant /proc entry than not. Do most of the work for the driver
writer.
-Matt