Date: 28 May 2003 18:07:49 +0100 From: Paul Richards <paul@freebsd-services.com> To: dave <leimy2k@mac.com> Cc: freebsd-current@freebsd.org Subject: Re: policy on GPL'd drivers? Message-ID: <1054141667.1792.5.camel@cf.freebsd-services.com> In-Reply-To: <248EFE3A-912C-11D7-AD30-000393D6D7EE@mac.com> References: <248EFE3A-912C-11D7-AD30-000393D6D7EE@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2003-05-28 at 17:48, dave wrote: > > > > I don't think anyone is talking about symbol versioning. The issue is > > stamping the API at a particular point in time that shows it behaves in > > a specified guaranteed way. > > > > The module system has all the hooks to deal with versioning. What's > > missing is not the mechanism but the knowledge, i.e. we don't know that > > module X won't work with kernel Y becuase we don't know what APIs > > module > > X may invoke and whether kernel Y supports them. > > > > <snip> > > > 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. The kernel wouldn't then load a module if the kernel didn't support the APIs that the module depended upon. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1054141667.1792.5.camel>