On Thu, 2009-03-19 at 23:58 +0100, Frans Pop wrote: > > I guess it's called progress ;) Sarcasm aside, if you can give me an > > example of an actual real life set of users who are adversely affected > > then I'll try to do something to help out. But if you're asking for old > > versions of software to be compatible with newer releases in every case > > I think you're not being terribly realistic. The kernel changes to make > > progress, and so do other utilities. > Sure, if there are very strong reasons to break things, fine. But whenever > possible the kernel has ensured backwards compatibility, mostly only > _after_ someone "complained". Think of the i386 and x86_64 symlinks after > the x86 integration, think of the COMPAT_SYSFS flags, think of optional > support for old /proc files, think feature-removal-schedule.txt. All of these examples refer to the future. The *future*. Things that will change, preserving backward compatibility, keeping symlinks around for those who are used to the old location. *Backward* compatibility. But the issue you raised was about *Forward* compatibility. This is nice but isn't the same. That would be like guaranteeing that all future kernel features will work with a kernel from 6 months ago, or that modules will, or other similar stuff. > So far you seem to be avoiding to give the reasons for the change. What > would be so wrong with ensuring the compatibility for some transition > period and avoiding the problem? There is compatibility. From the past, to the present, into the future. But you want to use *future* generated files with a *past* version. That is not backward compatibility and it is not the kind of thing where you can "preserve for 5 years", etc. How does the old version know something is going to change? It doesn't and it can't. v3.4 will always be the same, and it won't change. The files changed slightly in v3.6, but v3.4 can never know about that. > P.S. Thanks a lot for your prompt replies. I do appreciate the discussion. Sure. Hopefully you see that this is not a regular compatibility issue. Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
