Rebuild all network-related kernel modules on 8-current due to
vnet allocator change
rwatson at FreeBSD.org
Tue Jul 14 23:41:54 UTC 2009
On Wed, 15 Jul 2009, Robert Watson wrote:
> The attached change, which just entered 8-current, modifies kernel
> programming and binary interfaces for many network stack components/modules.
> You will want to make sure all kernel modules are rebuilt.
FYI, for those following this work, there are a few more loose ends to tie up:
- libkvm needs to know how to do the per-vnet variable translation for symbols
on a virtualized kernel. I have a prototype already, but I'm currently
considering the API implications.
- kgdb needs to make it easier to print virtualized global values, perhaps by
providing a script wrapper (which requires a small kgdb extension to provide
a typeof() operator similar to C), or perhaps in the kgbd implementation
- We inherited VNET_GET() from the DPCPU code, but actually we might just want
to make it VNET().
Unmentioned in the commit message was that DDB has learned how to do the
translation from per-CPU and per-vnet allocated globals automatically. If you
do "print if_index", for example, it first tries to look it up as a regular
symbol -- if the kernel is compiled with VIMAGE, this will fail and it will
then look for a per-CPU variable, and when that fails (since there isn't one),
it will try a per-vnet variable, do the translation, and print as normal.
By default, we use the kernel CPU's dynamic per-CPU data, and the current
thread's per-vnet data, but these can be adjusted using DDB variables ($db_cpu
shows the CPU to use, or -1 to use whatever the current CPU is (default),
$curcpu shows what the current CPU is. $db_vnet shows what vnet to use, or
NULL to use the current vnet (default), and $curvnet shows what the current
vnet is). This should make it significantly easier to inspect/get/set per-CPU
and per-vnet globals from DDB.
And, with the new world order, !VIMAGE kernels now behave as they did
previously, with normal symbols for all network stack globals.
Robert N M Watson
University of Cambridge
More information about the freebsd-current