On Fri, 2010-10-08 at 13:49 -0400, Frank Ch. Eigler wrote: > Hi - > > On Fri, Oct 08, 2010 at 01:21:35PM -0400, Steven Rostedt wrote: > > [...] > > Perhaps we should have "make install" of a kernel also install this > > library? > > [...] > > The app only needs to worry about loading the generic library. The > > generic library can test for compatible libraries for the kernel. > > [...] > > If this library were to be distributed with the kernel, what would > make the generic side of the interface any less permanent than a > kernel ABI? That is, if there is a libkernel-internals.so built from > kernel sources, wouldn't its ABI become necessarily as fixed as any > old syscall or procfs file? One thing, the backwards compatibility would reside in user space. The big advantage to that than for this to be in kernel space is that it is only there when used. When we have backward compatibility in the kernel, it's there in memory for everyone, whether you want it or not. > > One can have some backward compatibility with symbol versioning et > al., but would that be sufficiently powerful to avoid handcuffing > kernel developers' inclinations to make random future changes? > Sure, also note, that this is a two lib design. We still have a /usr/lib/libkernel.so that the apps will interface with. This will need to load in the other kernel versions. When we change interfaces, we can make the /usr/lib/libkernel.so.1 .2 etc. Also doing this dynamically from a library, we can check if the kernel versions work. It can test if the used function is compatible or not, use an older version, or just tell the user "sorry, please update your libkernel.so for this kernel." Doing this in userspace will allow a lot more flexibility. We just need to think hard how these transactions will work, and make it flexible for future enhancements. But the kernel is free to do whatever it wants. The libraries will need to worry about keeping the applications happy ;-) -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|