itojun@iijlab.net writes:
> 	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:

> -- packed
> static int loc[321] = {
> static short pv[183] = {
> 
> -- non-packed
> static int loc[806] = {
> static short pv[1084] = {

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-)



> 	It may be better if we just malloc and copy, only when we make
> 	changes in UKC, given the frequency we may use UKC (I think I use it
> 	as workaround, though I can be wrong).

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.)


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.)

* 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...



cgd