>>> Keith Owens <[email protected]> 10.11.05 06:44:52 >>>
>On Wed, 09 Nov 2005 15:09:13 +0100,
>"Jan Beulich" <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
