Subject: README: dynamic sysctl
To: None <current-users@NetBSD.org>
From: Andrew Brown <atatat@atatdot.net>
List: current-users
Date: 12/04/2003 15:56:14
it took a while, but i've just committed complete rewrite of the
kernel's sysctl infrastructure to the tree. it might sound a little
scary, but it's a good thing.
off the top of my head, here's a high-level view of some of the new
features:
* the kernel knows about (but does not currently use) the name to
number mapping for each node. auto-discovery of the tree is now
possible, meaning that sysctl(8) will never have to be recompiled
(unless, of course, there's a new structure it needs to be taught to
print).
* nodes can now be added to the tree by lkms, by device attachment
routines (eg, when autoconfigure runs or when you plug in a pccard
or usb device), or at securelevel 0 from the command line via the
new and improved sysctl(8) binary (though there are currently, and
unfortunately, some port-specific limitations on this, though some
simple experimentation should show whether it works for you or not).
* adding new nodes (or subtrees) to the sysctl tree is now much
simpler, and nodes can be instantiated alongside the data they're
instrumenting. this means that a lot of the convoluted exporting
and externing of variables can be done away with shortly, and the
"spaghetti" involved in getting those nodes to be accessed by/from
sysctl() is gone.
all the nodes that existed before now are still there, and at the same
place. this means that your old programs should work perfectly well
with a new kernel, but the converse is not the same. of course.
well...you might win, but i wouldn't put money on it.
i tried to be as tedious and conscientious as possible with this,
since not only did i have to muck with 30 ports' machdep.c files (in
order to rip out and replace their cpu_sysctl() routines), but
everything relies on sysctl, so if it doesn't work, you're pretty much
toast. this is where the wonderful feature of cross-compilcation
comes into play, because i was able to cross-compile 150 kernels for
those 30 architecures over the last few days (75 "clean" and 75
"dirty", so that i had a baseline). they all built, but i can't boot
all of them myself (i don't, for example, have any sun2 or mvme68k or
macppc machines). nevertheless, here are the resulting sizes, so that
you can see the impact of all of this:
architecture config clean dirty size change
alpha FRAU-FARBISSINA 4330619 4374683 (+44064 bytes)
alpha FROGS 3519121 3564301 (+45180 bytes)
alpha GENERIC 7160252 7201871 (+41619 bytes)
alpha INSTALL 8783195 8818020 (+34825 bytes)
amd64 GENERIC 7955606 8003214 (+47608 bytes)
amd64 GENERIC.MP 8064679 8116343 (+51664 bytes)
amd64 INSTALL 8194806 8237167 (+42361 bytes)
amd64 INSTALL_ACPI 8560938 8603299 (+42361 bytes)
amiga AMIGA 3266632 3295882 (+29250 bytes)
amiga DRACO 2631701 2660904 (+29203 bytes)
amiga GENERIC 3272384 3301650 (+29266 bytes)
amiga INSTALL 2527089 2553672 (+26583 bytes)
atari ATARITT 2681609 2710805 (+29196 bytes)
atari BOOT 1245233 1270293 (+25060 bytes)
cats GENERIC 4719202 4757776 (+38574 bytes)
cats INSTALL 4764136 4792804 (+28668 bytes)
cesfic GENERIC 1204090 1227602 (+23512 bytes)
dreamcast GENERIC 1732639 1762047 (+29408 bytes)
hp300 GENERIC 2834102 2863980 (+29878 bytes)
hp300 INSTALL 1225524 1248551 (+23027 bytes)
hp700 GENERIC 5861585 5916456 (+54871 bytes)
hp700 SMALL 3987365 4041188 (+53823 bytes)
i386 GENERIC 7174731 7204157 (+29426 bytes)
i386 GENERIC.MP 7367791 7398401 (+30610 bytes)
i386 GENERIC.MPDEBUG 7468725 7495239 (+26514 bytes)
i386 GENERIC_TINY 1579507 1601970 (+22463 bytes)
i386 INSTALL 8977566 9000829 (+23263 bytes)
i386 INSTALL.MP 9253858 9279202 (+25344 bytes)
i386 INSTALL_LAPTOP 7640706 7663997 (+23291 bytes)
i386 INSTALL_PS2 3478990 3504452 (+25462 bytes)
i386 INSTALL_SMALL 3447489 3468290 (+20801 bytes)
i386 INSTALL_TINY 2811318 2831885 (+20567 bytes)
i386 SYSCTL 7364859 7394471 (+29612 bytes)
i386 THAT2 3982940 4011250 (+28310 bytes)
luna68k GENERIC 1260272 1286354 (+26082 bytes)
mac68k GENERIC 2719208 2748875 (+29667 bytes)
mac68k INSTALL 4341893 4365431 (+23538 bytes)
mac68k SMALLRAM 1457893 1481756 (+23863 bytes)
macppc GENERIC 5057602 5098976 (+41374 bytes)
macppc GENERIC.MP 5134613 5175971 (+41358 bytes)
macppc INSTALL 4317843 4350905 (+33062 bytes)
macppc POWERMAC 1718913 1752374 (+33461 bytes)
mmeye GENERIC 1955314 1988260 (+32946 bytes)
mmeye MMEYE 1091703 1118096 (+26393 bytes)
mvme68k GENERIC 1832319 1859352 (+27033 bytes)
mvme68k VME167 1296285 1321280 (+24995 bytes)
news68k GENERIC 2069878 2100440 (+30562 bytes)
news68k INSTALL 2422792 2445899 (+23107 bytes)
next68k GENERIC 2100003 2128886 (+28883 bytes)
next68k SLAB 1727129 1754617 (+27488 bytes)
sgimips GENERIC 3612291 3651721 (+39430 bytes)
sgimips GENERIC_INDY 3614067 3653497 (+39430 bytes)
sgimips INSTALL32_IP2x 6374032 6413946 (+39914 bytes)
sgimips SYSCTL 3735815 3775697 (+39882 bytes)
sparc GENERIC 3409599 3450126 (+40527 bytes)
sparc GENERIC.MP 3516159 3557566 (+41407 bytes)
sparc GENERIC_SUN4U 5699610 5741088 (+41478 bytes)
sparc INSTALL 2388900 2417012 (+28112 bytes)
sparc64 GENERIC 5485337 5524580 (+39243 bytes)
sparc64 GENERIC.MP 5582288 5622323 (+40035 bytes)
sparc64 GENERIC32 5695898 5737376 (+41478 bytes)
sparc64 INSTALL 10611682 10646425 (+34743 bytes)
sparc64 SPLODE 2927102 2968297 (+41195 bytes)
sun2 FOURMEG 1082684 1106023 (+23339 bytes)
sun2 GENERIC 1409820 1436452 (+26632 bytes)
sun2 INSTALL 1083827 1107336 (+23509 bytes)
sun3 GENERIC 1736438 1765920 (+29482 bytes)
sun3 GENERIC3X 1765327 1795000 (+29673 bytes)
sun3 INSTALL 1077319 1100319 (+23000 bytes)
sun3 INSTALL3X 1104912 1128023 (+23111 bytes)
vax GENERIC 2028201 2054927 (+26726 bytes)
vax GENERIC.MP 2148188 2175998 (+27810 bytes)
vax INSTALL 2661095 2681404 (+20309 bytes)
x68k GENERIC 2097158 2126050 (+28892 bytes)
x68k INSTALL 2781748 2807362 (+25614 bytes)
i tried to build some pc532 and evbsh3 kernels as well, but they
didn't cooperate (their own issues, not mine).
now, while i tried to keep this all as clean as possible (which is why
i've been poking and prodding and testing and banging and pounding on
it for a while now), there is sure to be some "fallout". off the top
of my head:
* some install media may need fixing, due to the increase in kernel
size.
* some lkms will need adjustment. if they add nodes to the tree when
they're loaded, they'll need code added that removes them when they're
unloaded. simiarly, if they implicitly added nodes to the tree under
the old way of doing things, they'll need to be adapted to the new way
of doing things.
but that's it. have fun. lemme know if you like it, if anything
seems broken, etc.
--
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org * "ah! i see you have the internet
twofsonet@graffiti.com (Andrew Brown) that goes *ping*!"
werdna@squooshy.com * "information is power -- share the wealth."