On Thu, 2012-01-12 at 10:39 -0500, Mathieu Desnoyers wrote: > pipe()/pipe2() > dup()/dup2()/dup3() > umount()/umount2() > mmap()/mmap2() > madvise()/madvise1() > eventfd()/eventfd2() > > Those look very much like major version numbers to me. And these are > entirely compatible with your statement above about using -ENOSYS to > detect if the major version number is implemented or not. That's a stretch in calling version numbers. All but the madvise case above are how many parameters it takes, not really a "version" number. It's adding a new syscall, not updating a version and then deprecating the old one. As I believe all the above are still supported. > > If your only concern is that the major version number should be part of > the ABI name (as in the examples above), that can be arranged. > > > > We've done this without version numbers. Just look at all the udev > > changes. > > Are you seriously refering to udev as an example of how to handle > changes, or as one of the worse ABI breakage mess that happened in the > Linux kernel history ? My own experience as a Linux users (in the > era around 2.6.12 kernels if my memory serves me right) lead me to think > it's the latter. And because udev is part of the runtime support, that > indeed led to non-bootable systems and lots of frustrated users. Yeah, I know it sucked, as I got burned by it too. But having "version" numbers wouldn't have helped at all. In fact, it should have kept both ways working much longer, or at least had the new udev support both. What udev did is more like what you want to do than what I did with trace-cmd. -- Steve _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
