Bart Smaalders wrote: > Note that exactly the same argument can be made for any bug fix; > what this argues for is virtually complete stasis, since any change > we make can and will cause problems for broken applications.
Its quite easy to label an application as "broken" after it fails subject to a change in environment or simply a new test. To one degree or another, greater that 99.44% of applications are broken. Its a real world we live in. > Indeed, we've seen exactly the same problem with a library that used > to dereference a user-supplied pointer, and then later this functionality > was done in the kernel. What had been a SEGV was turned into a > EFAULT, and the application misbehaved in a new way. OK. I now have been given two appropriate stories to tell. I felt I needed to address some assertions on the mail-trail about "can't cause a failure". If everyone can accept that it can happen, we can shorten the discussion about "how significant" or "how often" to simply the risk/benefit discussion. > I don't think requiring all previously broken programs to fail in exactly > the same manner across all update releases of Solaris 10 is a reasonable > standard, and is certainly not one that we follow. Jim already > pointed out > that the introduction of new options for existing commands would cause > the same sorts of problems. Adding new codes to an ioctl would as well. Exactly. (Well, update/minor, but we are past that.) Its all about risk/benefit. Taking such risks for "familiarity" in an area where we are not instructed to strive for "familiarity" seems like a very poor bet. (As for Jim's example, this is an area where we are instructed to strive for "familiarity". That changes the ratio.) For some reason "stasis" seems to be a harsh word, but it is exactly appropriate. Taking no risks for significant benefit is wrong. Just the same, taking risks for only negligible benefit is also wrong. I'm only asserting that we should evaluate this careful - hopefully objectively. > - Bart - jek3
