On Thu, 2012-01-12 at 09:09 -0500, Mathieu Desnoyers wrote: > It is important to clarify that tracing is, in my opinion, not part of > the runtime support, which makes it very different by nature from > filesystems and kernel runtime support. So I agree with Linus' argument > about not breaking userspace when applied to runtime support, because > being unable to even boot a system due to an ABI breakage is very much > unwanted. However, I think it should not be applied as-is to tracing, > because you cannot make a system unusable due to a tracer ABI breakage: > if a tracer can be packaged in a set of standalone modules, that clearly > shows it is not part of the system runtime support. Correct that tracing is not something that needs to make the system run, but that's still no excuse to make ABI changes any different. Note, we don't change things within the /proc/stat or /proc/*/stat and that's not required to make the system run. We can add onto those files, but we can't change what the current numbers mean. > > That being said, ABI versioning could still handle ABI changes without > significantly impacting the users: when an ABI breakage is needed, we > can keep the old code around for a while and expose both the old and new > ABIs. This would ensure that the user-level tools can query for the > specific ABI major version(s) they support. That should improve the user > experience by providing "deprecated" console warnings for a few kernel > releases before the old code ends up being removed. ABI version numbers are meaningless, and prone to be broken. The change would have to be added with the commit that updates the change otherwise git bisecting can get screwed up too. The way ABI changes in the kernel have always been was to look at the file itself and have the tool be able to determine what version of the ABI is there based on what files exists, or what exists in the file. I've done this with trace-cmd and ftrace. The debugfs system has changed a lot, and trace-cmd can handle each change. I never had a need for a version number to do this. I simply have trace-cmd look at what is available and what isn't. If you need to know if a syscall exists, you try it and if you get -ENOSYS, then you know it doesn't exist. We have no need for an arbitrary version number that is meaningless. The existence of (or lack of) tells us all we need to know. > > So, in summary: > > * Old kernels vs new tools: > > New tools can query for the latest ABI they know, and fall-back on older > ABIs, with limited features. > > * New kernels vs old tools: > > Keeping around the old ABI for a deprecation phase lets old tools work on > a bleeding edge kernel while the ABI change is being introduced, which > should satisfy the kernel developer use-case. We've done this without version numbers. Just look at all the udev changes. -- Steve _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
