|
On 06/07/2012 07:34 PM, Ben Hutchings
wrote:
This is not my department, but as I understand it, Matthew Garrett received complete source code in response to each of his various requests for Ksplice source code. This is where I disagree. Debuginfo is both huge (since it contains lots of data beyond the basic symbol information in kallsyms) and is also not necessarily available on user systems, meaning that any sort of patching or debugging tool intending to get wide use can't rely on it. Further, any system which contains third-party modules (open source or not) will not have symbol data for those modules unless the vendors of those third-party modules provide a separate debuginfo package (many do not); with kallsyms, you're guaranteed to have accurate information that comes from the modules that are actually loaded on the system.> To briefly clarify my original email, it is true that enabling > CONFIG_KALLSYMS_ALL would make life slightly easier for Ksplice and > similar tools that look at kernel data structures (e.g. debugging > tools). No doubt true, but it is also strictly redundant with debuginfo. As I think I mentioned before, when folks upgrade the kernel version on disk on a Debian system and don't immediately reboot (which folks do _all the time_ whether they're using Ksplice or not), and then load kernel modules, they'll get kernel modules from the upgraded kernel (at least in the common case where the ABI doesn't change). As a consequence, if you're any sort of debugging/instrumentation tool that inspects the running kernel's code, you need to be able to handle the case where the kernel is running modules that don't actually go with either the running kernel (via "uname -a") or the currently version of the linux-image-* package installed on disk. Trying to do anything to get symbol information in that sort of situation using debuginfo is a disaster; what you want is kallsyms. CONFIG_KALLSYMS_ALL adds less than 1% to the size of the kernel over CONFIG_KALLSYMS (obviously this depends on what options one had enabled in the first place), so only on truly embedded settings will that matter at all. Could you at least just enable it for the architectures where none of Debian's stock kernels are designed for embedded environments (e.g. x86, sparc, power)?> That said, Ksplice doesn't require CONFIG_KALLSYMS_ALL -- > the Ksplice Uptrack service has been providing updates for systems > running Debian Linux since 2009. While your enabling > CONFIG_KALLSYMS_ALL might allow us to delete like 50 lines of code 2 > years from now when Squeeze reaches end of life, I submitted this > bug report primarily because I'd like it to be the case that other > folks developing similar innovative new technologies don't have to > do the extra work of supporting !CONFIG_KALLSYMS_ALL in order to > support all the major Linux distributions. I hope you'll consider > my suggestion on its technical merits. I'm going to have see a request from an actual other person before I care to spend time on this. (In case anyone else in the kernel team wants to proceed with this, that's not a NAK. The issue is that memory and/or flash partition constraints make this unsuitable for some configurations, and you'll need to work out which ones to enable it for.) -Tim Abbott |