lkml.org 
[lkml]   [1996]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: proposal for generic interface to /proc text files
> >I would like to see a clean break to tagged text for *all* proc files. 
> >That way we only get caught once when the change is made, thereafter user
> >mode utilities will simply ignore /proc fields they do not recognise,
> >making for a much cleaner upgrade path.
>
> How often do common /proc entries change? Very infrequently. This
> is overkill for a rare problem. We need to find a solution that is
> a little more subtle. These issues can be addressed with less
> draconian measures that what you are proposing. Heck, a simple
> policy, such as "when kernel changes affect a large enough
> user base, some means of backwards compatibility must be
> maintained" would be immensely helpful. It would definitely solve
> the problem you are attempting to address. Fortunately most
> developers follow these words of wisdom already.

Generic "backwards compatibility" is ugly. It typically implies either

1) Clients that support many versions of an interface (gross)

or

2) Interfaces that don't get fixed properly because it won't be backwards
compatible (also gross).

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.

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".

Ty


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.115 / U:0.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site