The only true solution to this is to version the APIs in the kernel and
use the module versioning hooks to not load modules if the version
isn't
the right one.
Will this require *any* new infrastructure to implement properly? Or is
it simply a matter of maintaining API metadata regarding versions.
I think it'd just be a question of maintaining the metadata. There may be a little code missing but I don't think it would take a lot of work to complete the versioning mechanism. Creating all the metadata to actually define and version the APIs is another issue entirely though.
Each module can maintain dependency data, stating which versions of other modules it can work with. The kernel would need to create virtual modules that held the faked module version for that API component. That wouldn't be very hard, just a linker set to record the API version in a module version structure. Ideally, whenever possible each API component should be grouped into a module anyway, but when that isn't possible just defining a faked module version should work.
So the module dependency graph would have "nodes" that are either real or virtual modules. Virtual modules are provided by the kernel proper only which only uses them to satisfy a module dependency?
Interesting [hope I got that correct :)]
Sounds like a neat way to create a module framework, guide for 3rd party and commercial drivers to get support from FreeBSD itself.
dave
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
