Alan Cox <[EMAIL PROTECTED]> writes: >> >> adequate job of warning our users. A printk when we run a program >> >> that uses the binary interface and an long enough interval the warning >> >> makes it to the Enterprise kernels before we remove the interface >> >> should be sufficient. > > The enterprise products will probably just remove the printk. Even if > they didn't you are looking at ten years before things finish changing > based on current experiences, probably longer as things stabilize. > > The whole "whine a bit" process simply doesn't work when you are trying > to persuade people to move in a non-hobbyist context. They don't want to > move, the message is simply an annoyance, their upstream huge package > vendor won't change just to deal with it and they'll class it as a > regression from previous releases, an incompatibility and file bugs until > it goes away.
My hypothesis. No one cares now. My observation. The way we have been maintaining the binary sysctl side of things using it is asking for your application to be broken in subtle and nasty ways. If that is true none of your enterprise concerns apply because it isn't used, or we will be breaking the enterprise application by accident anyway in a much more difficult way to diagnose. Right now there is only one way to find out. Plan on removing it and see what the fallout really is. If the grace period needs to be longer then 2 years I have no problem upping it. If my hypothesis is wrong and there are real users who care that aren't easy to change I don't mind keeping it. > Its user ABI and as Linus said - we don't break it. Trimming down all the > crap that never worked via sysctl is one thing, not putting sysctl in new > platforms likewise. Trying to undo it isn't going to work Then this will fail and we will have a good case for maintaining sys_sysctl. No breaking user space is the point of the grace period. At the rate things are going now I suspect that we will wind up removing sys_sysctl one entry at a time as we discover new and interesting ways that the code has been broken through bad maintenance. I am very much in favor of not breaking user space, and preserving a binary ABI. I think we can best avoiding breaking user space applications by getting them to avoid sys_sysctl, and getting them to stop if they already are. This isn't "Oh some apps are using it let's get them to stop, because it is inconvenient". This is "No apps seems to be using this, we keep goofing up the maintenance and no one notices, and so it is likely a source of security problems and other nasties" I have evidence that there are 1 or 2 open source applications using this (not counting the glibc weirdness). Although the ones I have found were either old installers or were already patched to not do this in some of the distros, or in the case of glibc really don't care. So currently I believe that after we spread the word far and wide in a way that people will listen to no one will have any real complaints and the proof that it is safe to remove will be complete. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
