>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.
Yes, but to know all the interfaces the module needs, you either need
to look at the source or reverse-egineer it. Actually, I'm pretty sure
reverse-engineering violates the license terms. So this buys you
nothing, someone with source access still has to make a new
distribution each time the kernel interfaces change.
>[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?
It's not my decision to make. But personally, I think "stable kernel"
should imply as little change as possible at any external interfaces,
preferrably none. The idea of adding a layer to isolate the module
from these changes seems like the cart pulling the horse to me, or to
be more vernacular, ass-backwards. Furthermore, it doesn't really save
any work. Someone with AFS source access still has to make a new
release every time kerne; interfaces chage, but the new component also
has to be recompiled when the AFS module changes.
>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.
>P.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.
This assumes that the AFS module is the only thing that cares about
module interfaces staying the same or is the only thing that ever
will. Not only that, but I have yet to see how this "adaptor" idea
does anything but create massive amounts of extra work.
- Maciej Stachowiak