mirror of https://github.com/tLDP/LDP
64 lines
3.6 KiB
Plaintext
64 lines
3.6 KiB
Plaintext
<sect1><title>Replacing <function>printk</function></title>
|
|
|
|
<indexterm><primary>printk</primary><secondary>replacing</secondary></indexterm>
|
|
|
|
|
|
<para>In <xref linkend="usingx">, I said that X and kernel module programming don't mix. That's true for developing kernel
|
|
modules, but in actual use, you want to be able to send messages to whichever
|
|
tty<footnote><para><emphasis>T</emphasis>ele<emphasis>ty</emphasis>pe, originally a combination keyboard-printer used to
|
|
communicate with a Unix system, and today an abstraction for the text stream used for a Unix program, whether it's a physical
|
|
terminal, an xterm on an X display, a network connection used with telnet, etc.</para></footnote> the command to load the
|
|
module came from.</para>
|
|
|
|
<indexterm><primary>current task</primary></indexterm>
|
|
<indexterm><primary>task</primary><secondary>current</secondary></indexterm>
|
|
<indexterm><primary>tty_structure</primary></indexterm>
|
|
<indexterm><primary>struct</primary><secondary>tty</secondary></indexterm>
|
|
|
|
<para>The way this is done is by using <varname>current</varname>, a pointer to the currently running task, to get the current
|
|
task's <structname>tty</structname> structure. Then, we look inside that <structname>tty</structname> structure to find a
|
|
pointer to a string write function, which we use to write a string to the tty.</para>
|
|
|
|
<indexterm><primary>source file</primary><secondary>print_string.c</secondary></indexterm>
|
|
|
|
|
|
|
|
<example><title>print_string.c</title><programlisting><inlinegraphic fileref="lkmpg-examples/10-ReplacingPrintks/print_string.c" format="linespecific"/></inlinegraphic></programlisting></example>
|
|
|
|
</sect1>
|
|
<sect1><title>Flashing keyboard LEDs</title>
|
|
<indexterm><primary>keyboard LEDs</primary><secondary>flashing</secondary></indexterm>
|
|
|
|
<para>In certain conditions, you may desire a simpler and more direct way to communicate to the external world.
|
|
Flashing keyboard LEDs can be such a solution: It is an immediate way to attract attention or to display a status condition.
|
|
Keyboard LEDs are present on every hardware, they are always visible, they do not need any setup, and their use is rather simple and
|
|
non-intrusive, compared to writing to a tty or a file.</para>
|
|
|
|
<para>
|
|
The following source code illustrates a minimal kernel module which, when loaded, starts blinking the keyboard LEDs until it is unloaded.
|
|
</para>
|
|
|
|
<example><title>kbleds.c</title><programlisting><inlinegraphic fileref="lkmpg-examples/10-ReplacingPrintks/kbleds.c" format="linespecific"/></inlinegraphic></programlisting></example>
|
|
|
|
<para>
|
|
If none of the examples in this chapter fit your debugging needs there might yet be some other tricks to try. Ever wondered what
|
|
CONFIG_LL_DEBUG in <command> make menuconfig </command> is good for? If you activate that you get low level access to the serial port.
|
|
While this might not sound very powerful by itself, you can patch <filename>kernel/printk.c</filename> or any other
|
|
essential syscall to use printascii, thus makeing it possible to trace virtually everything what your code does over a
|
|
serial line. If you find yourself porting the kernel to some new and former unsupported architecture this is usually
|
|
amongst the first things that should be implemented. Logging over a netconsole might also be worth a try.
|
|
</para>
|
|
|
|
<para>
|
|
While you have seen lots of stuff that can be used to aid debugging here, there are some things to be aware of.
|
|
Debugging is almost always intrusive. Adding debug code can change the situation enough to make the bug seem to dissappear.
|
|
Thus you should try to keep debug code to a minimum and make sure it does not show up in production code.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
|
|
<!--
|
|
vim: tw=128
|
|
-->
|