Subject: Re: LKM versioning
To: Jaromir Dolecek <email@example.com>
From: Andrew Brown <firstname.lastname@example.org>
Date: 04/15/2003 14:47:10
>> 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
how about "each interface that wants one gets its own version number,
but otherwise the interface falls back to regular __NetBSDVersion__
so we would (arbitratily) currently be at UVM version 2, DEVSW version
>I'll try to evaluate the proposed LKM versioning scheme
>and post diff later.
|-----< "CODE WARRIOR" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."