kmed - Example of a remote kme daemon
- kmed
- [-c corefile] [-e endian]
[-r] [-U port]
[-D debug]
Kmed is an example of a remote daemon for kme(1). Kmed
communicates with kme over a socket using a simple custom UDP protocol
called RW (for read-write). The example version of kmed is
useful as-is for many debugging situations. kmed, however, may require
customization in order to provide access to some types of hardware.
Kmed can provide access for kme to more than one
corefile (special device file) at a time. From kme, the Nth
corefile is accessed by prefixing the memory/device address with
NN:, where NN is zero-based (i.e. 00; refers to the
first corefile, 01: refers to the 2nd corefile,
etc.);
Command line options include:
- -c corefile(s)
- A colon-separated list of pathname(s) or device names which the remote
kme will be given access to. An unadorned pathname will be accessed
using open(), close(), lseek(), read(), and write().
-
-
Two alternative syntaxes are available for corefile, and both allow
access to the corefile by using mmap() to map the corefile
into the kmed process. Mmap() is very useful when you want to
access the /dev/mem special file on Linux.
-
- A fixed mmap()ing is selected with the syntax:
corefile,offset,size. In this case, size bytes at
offset from the start of the corefile are mmap()ed. This is
useful if you want to access just a small region of a special device file.
offset and size are interpreted in hexadecimal when prefixed
with 0x, otherwise they are decimal.
-
-
A floating mmap()ing is selected with the syntax: corefile,1,size. In
this case, size bytes are mmap()ed, but the offset of the
mmap() will be determined based on the addresses that kme requests.
The offset may change over and over depending on what kme needs to
display or modify. This is useful if you want to access into a potentially
large area of a special device file. However, there may be performance
implications if the addresses that kme needs bounce all over the
place. A well designed kme_defs file and kme display can
minimize this problem.
-
-
The default for corefile is /dev/kmem.
- -e endian
- Unfortunately, the original RW protocol was designed eons ago with
no consideration given to the endianess of the protocol. This can cause
problems when kme and kmed are running on computers with
different endianess. The endian option can be set to 0
(as-is), 1 (big-endian), or 2 (auto detect). The default is
to autodetect the endianess, and this usually works.
- -r
- Open the corefile(s) for read access only. The default is to open
the corefile(s) for both read and write access.
- -U port
- The UDP port number to use for communications with kme. The
default is port 2773.
- -D level
- Set the debug output level for debugging kmed itself. The
default is 0 (no debugging output).
Simple access to /dev/kmem:
# kmed &
The 1st corefile is /dev/kmem and is accessed using lseek(),
read() and write(). The 2nd corefile is a floating mmap() of /dev/mem with a
size of 4096 (one kernel memory page).
# kmed -c /dev/kmem:/dev/mem,1,4096
&
The definitive specification of the RW protocol is the header file
kme.h and the source code for kme.c. The protocol is UDP based
(datagrams).
When kme wants to read a memory location, it sends an
rw_t packet to kmed and expects an rw_t packet in
response. It tries this a few times, and then gives up and displays
???????? for that location. If the response was lost due to temporary
network congestion it is not a big deal because kme will reissue the
read request on the next display cycle.
A similar thing happens with write requests. But in case all of
the retries of the write request are lost, the user will notice that the
value hasn't changed and reissue the kme change command.
Obviously, this does not work well for hardware registers that are
write-only. In addition, network congestion could cause kmed to see
two or more write requests before kme sees the reply from
kmed. For some hardware registers, multiple writes could cause
unexpected behavior.