#include <sys/ksym.h> #include <sys/elf.h>
int getksym(char *symname, unsigned long *value, unsigned long *info);
|STT_FUNC||text symbol (typically function)|
The symbol name can be no more than MAXSYMNMLEN characters. If more than one symbol of the given name exists in the search space, the one (if any) in the statically bound kernel or, if not there, the first one found among the loaded modules will be returned.
If getksym is given a valid address in the running kernel in the space pointed to by value, it will return, in the space pointed to by symname, the name of the symbol whose value is the closest one less than or equal to the given value and, in space pointed to by info, the difference between the address given and the value of the symbol found. The space pointed to by symname must be at least MAXSYMNMLEN characters long.
Finding out the address of a particular kernel variable was commonly done by using nlist(ELF) on /stand/unix. This is no longer an accurate way to get that information, since /stand/unix only contains the symbol table for the static kernel. The symbol tables for the loadable modules are elsewhere on the system, but which modules are loaded and from where changes over time. So, as part of this feature, two new ways of getting at information associated with kernel symbols have been provided.
The getksym(S) system call provides the kind of information on a given kernel symbol or address that nlist(ELF) provided. However, the symbol name/address association may not be valid by the time it is returned to the user (for example, if the symbol is defined in a loadable module and that module is unloaded), unless the user takes special steps like keeping the module loaded by making sure there is an outstanding open, mount, . . .
Because of this later complication and because most interest in kernel addresses is related to reading or writing from /dev/kmem, an alternate atomic method of reading and writing in the kernel address space based on a symbol name is provided. Three new ioctl commands now exist in the mm memory driver for the /dev/kmem minor device [see kmem(HW)]. In this way, a user gets the desired IO operation accomplished without fear that a module may be unloaded in the middle. Of course, this user must still open /dev/kmem for the correct type of IO and so the appropriate protections against unauthorized access still exist.