Messages in this thread | | | Date | Fri, 25 Apr 1997 00:08:23 -0400 | From | Raul Miller <> | Subject | Re: kernel structures in 2.0.29->2.0.30 |
| |
On Apr 24, Simon Karpen wrote > However, after the fs/inode.c fixes in 2.1.31, i do agress that, > at least on intel, we should try to maintain module compatability. > btw, do you know of any binary-only modules besides afs/linux and > oss?
I think the afs approach to binary only kernel modules under linux is wrong. It's not as if it's any big secret that the kernel module interface is intended as a source-code interface, and that it's expected to drift across linux versions....
For binary-only modules, the right thing to do is
(a) design an interface that reflects the functionality needed by the module.
(b) design an interface between the module's binary interface and the kernel's module interface. Distribute (b) in source form.
For the most part, (b) should be pretty trivial -- there's no reason why it couldn't be just a bunch of pass-through hooks for some linux version. However, as linux drifts it can be updated (as best as possible) for new kernel versions. Some new functionality may fail (where the datastructures don't map onto the expectations of the binary interface), but that should be a clean failure (or better yet, a slight degredation in performance) when such conditions are reached -- instead of a complete failure to operate.
I don't know if the current afs binary interface can be salvaged by the people who are interested in afs. But it's really silly for people to try to enforce a binary interface where a source interface was designed.
-- Raul
| |