Messages in this thread |  | | Date | Tue, 1 Oct 1996 11:50:03 +0100 | From | Matthew J Brown <> | Subject | Re: proposal for generic interface to /proc text files |
| |
Tyson D. Sawyer writes: > Generic "backwards compatibility" is ugly. It typically implies either > > 1) Clients that support many versions of an interface (gross) > 2) Interfaces that don't get fixed properly because it won't be backwards > compatible (also gross).
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
|  |