Date: Wed, 28 May 2003 12:57:54 -0500 From: dave <leimy2k@mac.com> To: Paul Richards <paul@freebsd-services.com> Cc: freebsd-current@freebsd.org Subject: Re: policy on GPL'd drivers? Message-ID: <E85E7D00-9135-11D7-AD30-000393D6D7EE@mac.com> In-Reply-To: <1054141667.1792.5.camel@cf.freebsd-services.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E85E7D00-9135-11D7-AD30-000393D6D7EE>