On Thursday 19 March 2009, Jon Masters wrote: [...] I understand how and why and when it works now. I can also easily avoid the problem now that I know about it. The question here is if the breakage is really necessary. I ran into the problem within days of installing the new m-i-t. I don't think I'm very special, so my guess is it's going to affect others too. > 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. No, sorry. That isn't, at least AIUI, how kernel (related) development is supposed to be done: http://lkml.org/lkml/2005/12/29/173 and similar discussions later. 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. 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? P.S. Thanks a lot for your prompt replies. I do appreciate the discussion. -- 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
