>> 	Yes it was (by furuta-san).  but after testing it myself,
>> 	I found that the locator tables (loc[] and pv[]) become 5 times bigger
>> 	than packed one.
>uh, well, actually:
>4 * 321 + 2 * 183 -> 1650
>4 * 806 + 2 * 1084 -> 5392
>5392 / 1650 -> 3.267
>not quite 5x.  what kind of kernel was that?  (if that was a
>GENERIC-ish kernel, i'd actually expect less expansion, even.)
>also, note that you're talking about like 4k.  4k is what fraction of
>a driver for a modern hardware device?  8-)

	I wasn't good at math :-)  if people says it's okay, I'm fine with it.
	BTW does it sound good to have command line option to /usr/sbin/config
	for controlling packed/unpacked locator table?

>I'm not familiar with UKC, so these questions may seem silly, but:
>
>UKC can store updated info in a kernel binary?  if so, and the locator
>data is not packed, where is the updated configuration information
>stored?  (either you overwrite packed locators, which is bad, or you
>have some special buffer into which overrides are written...  and the
>latter means that you can run out of space in which to store changes
>which would also seem bad.)

	openbsd UKC has three parts:
	- interactive editor in kernel, which updates locator table
	  right before device attach.  it will save whatever changes the user
	  made into history buffer.
	- "config -u /kernel".  based on history buffer in the running kernel,
	  update locator table in kernel binary.
	- "config -e /kernel".  bring up interactive editor, and let the user
	  tweak the kernel for the next bootup.

	If we implement 2nd and 3rd item, yes, we will need unpacked locator.

	However, I think 2nd and 3rd part should be solved like bsdi did:
	- /boot reads in /etc/boot.default, which is a plaintext file
	  that contain directives to tweak locator table (like "disable ne2")
	- kernel tweaks locator table as necessary.
	It is better, since it allows the following case, which looks
	harder with openbsd's "config -u" or "config -e":
	- we can tweak multiple kernels with single /etc/boot.default.
	  tweak usually belongs to particular machine, not to particular
	  kernel.  for example, for particular notebook I want to always say
	  "com2 is on irq 10".
	- we can tweak kernel config for different architecture
	- does not modify kernel binary itself
	- we can tweak kernel binary even if we have gzipped kernel in boot
	  floppy, as long as we can edit /etc/boot.default into boot floppy
	  (i.e. if we can mount it - FFS_EI)

	openbsd way (config -e) gives uniform interactive interface, which
	is a plus.

>random musing about things that would be nice:
>
>* the ability to run the re-configuration program on a non-NetBSD
>system, or a machine which isn't the same MACHINE or MACHINE_ARCH as
>the machine whose kernel is being tweaked.  (this is actually fairly
>important, really.)

	As I said, if we take bsdi approach it's fairly easy.  not sure
	if openbsd UKC (specifically config -e) addressed this.

>* the ability to add new instances of devices which, e.g. you have
>com3 at some ISA address/IRA, etc., and you want to add a new com at
>isa at a weird address, or something...

	openbsd already did that, by adding couple of empty entires into
	the very last part of cfdata[].  the PR does not have this part
	yet.

itojun