Messages in this thread |  | | | Date | Thu, 10 Nov 2005 09:02:31 +0100 | | From | "Jan Beulich" <> | | Subject | Re: [PATCH 14/39] NLKD - kernel trace buffer access |
| |
>>> Keith Owens <kaos@sgi.com> 10.11.05 06:44:52 >>> >On Wed, 09 Nov 2005 15:09:13 +0100, >"Jan Beulich" <JBeulich@novell.com> wrote: >>Debug extension implementation for NLKD to access the kernel trace >>buffer. > > printk.c | 187 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 187 insertions(+)
>This is complete overkill in printk.c. The only change required to >printk is to add a routine which gets the parameters that define the >buffer, see below from KDB. The rest of the code in your patch belongs >in the debugger, not in printk.
This depends on the perspective...
>#ifdef CONFIG_KDB >/* kdb dmesg command needs access to the syslog buffer. do_syslog() uses locks > * so it cannot be used during debugging. Just tell kdb where the start and > * end of the physical and logical logs are. This is equivalent to do_syslog(3). > */ >void kdb_syslog_data(char *syslog_data[4]) >{ > syslog_data[0] = log_buf; > syslog_data[1] = log_buf + log_buf_len; > syslog_data[2] = log_buf + log_end - (logged_chars < log_buf_len ? logged_chars : log_buf_len); > syslog_data[3] = log_buf + log_end; >} >#endif /* CONFIG_KDB */
The publishing of this function allows uncontrolled access to the otherwise (and sure purposefully) static symbols; you could as well globalize the symbols directly. In order for KDB to be a module, this symbol would even need to be exported. By keeping the debugger access code in the same file, nothing gets changed visibility-wise for the outside world.
Further, the design of the debugger extensions of NLKD calls for the extension code to live in the place their data gets controlled at. Consider an extension living in a module - how could the debugger access that information?
Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |