Re: policy on GPL'd drivers?

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]