lkml.org 
[lkml]   [1997]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.068 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site