There is a 'debian way' of making packages for kernel modules not in the 
kernel tree, producing a package that depends on the kernel package you make. 
I used it to keep the fuse module up to date a while ago. I'll see if I can 
find my notes on the details if you like, but make-kpkg rings a bell.

On Wednesday 11 January 2006 12:45, Denis Chapligin wrote:
> Hello!
>
> On Wed, Jan 11, 2006 at 09:53:50AM +0900, Stephen J. Turnbull wrote:
> > >>>>> "Denis" == Denis Chapligin <chollya_at_satgate.net> writes:
> >
> >     Denis> My problem is that i'm trying to build kernels in 'debian
> >     Denis> way', so i have a single .deb package with kernel, some
> >     Denis> patches, additional modules and so on. But coda module
> >     Denis> requires additional work in this case and it comes to be a
> >     Denis> problem whan you have several dozens of servers:) So
> >     Denis> providing a kernel patch for coda module will make a life
> >     Denis> easier .
> >
> > But why should there be a separate patch for something that is already
> > in the kernel?  If the module distributed with the kernel doesn't work
> > for you, let's fix it!
>
> But the additional kernel module is provided for every version of coda
> client....
>
> > >From what Jan says, I guess there's a backward compatibility problem
> >
> > with the old implicit-single-realm kernel code and the modern explicit
> > realms code.  That should be fixed by adding two build suboptions to
> > build with the realms code and without, not by maintaining a separate
> > patch.  (Either or both modules could be built, and they would be
> > named "coda-realms" and "coda-norealms".)
>
> The out-of-box kernel module doesn't supports realms. So i have to
> compile new module manually (i.e. not during automated kernel compilation
> process) and then manually copy it to all my servers.
>
> > This way you could (in theory) upgrade an individual client on-the-fly
> > with "modprobe -r coda-norealms; modprobe coda-realms".  Of course it
> > probably won't work so well in practice, but at least this would mean
> > every kernel would be ready for upgrade simply by switching modules.
>
> There could be a lot of problems with versioning and so on. But sounds
> good :)