Raul Miller:
> >(3) It should be possible for someone to hack together a wrapper for
> >the older module. This would translate between the new data
> >structures and the old at function invocation and return time. [Yes,
> >there's a performance penalty, yes it's work].
Maciej Stachowiak:
> This is probably more work than recompiling the module, and for
> someone to do this he would almost certainly need acccess to the AFS
> source anyway.
As you have pointed out, the work required to recompile the module is not
the only issue. There are far more people who have permission to link
code with the module than there are who have permission to build a new
module.
[However, since I don't have access to afs, I'm not going to tackle
this project.]
Yes, the legal restrictions (and lack of interest on the part of
transarc) have a cost both in terms of interface complexity and in
terms of efficiency. I would prefer to keep that cost localized
around the transarc afs kernel module, rather than propagating it
throughout the rest of the kernel.
Don't you think that's fair?
Note that, once an adaptor has been written, it should be possible to
build a version of insmod which knows about adaptors and can do the
right thing when linking the module to different kernel versions.
-- RaulP.S. I'm not suggesting that the kernel developers not learn anything from dealing with this afs module. I'm suggesting that the afs module could be adapted to a variety of potential kernel module interfaces.