>> USE_TOPDOWN_VM might be another one.  i'm not sure...
>
>Yes, if it changes structures exported to outside uvm.

it doesn't, but it does affect the definition of the
VM_DEFAULT_ADDRESS() macro.  of course, if your module doesn't
allocate memory for processes, you don't need to worry.

>> as long as the code i have in one module
>> ...
>> still works, i don't mind :)
>
>Yes, it will - this change only affect whether or not you'd be able
>to load the module, not any interface.

then each interface would have to be versioned, no?

>My intent is to structure the version in such a way as to catch
>most fatal ABI mismatches. Currently, we don't do any check of LKM
>version, so any improvement would be nice. The versioning scheme
>might change any time; it would just mean that LKMs done for previous
>releases don't work in then-current release, which is a axiom
>anyway.

how about "each interface that wants one gets its own version number,
but otherwise the interface falls back to regular __NetBSDVersion__
interface number"?

so we would (arbitratily) currently be at UVM version 2, DEVSW version
1, etc.

>I'll try to evaluate the proposed LKM versioning scheme
>and post diff later.

good.

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