[OpenAFS] Monolithic kernel (linux > 2.6.8) without loadable
modules support
Jeffrey Hutzelman
jhutz@cmu.edu
Wed, 30 Mar 2005 17:19:46 -0500
On Monday, March 28, 2005 11:26:30 PM +0000 "P.L.Freemak"
<xcondor@freemail.it> wrote:
> where I work we are evaluating a large deployment of clients and linux
> servers interconnected via openAFS. We'd like to start with a test on two
> servers replicating some folder with openAFS. My problem is that an
> enterprise wide security policy enforce me to deploy every server
> without loadable modules support. I would like to ask if is it possible
> in some way to have a linux kernel (version > 2.6.8) compiled without
> loadable modules support fully supporting openAFS read and write. I've
> seen that the kernel built-in openAFS support is read only.
Well, for starters, it's worth noting that "OpenAFS" is the name of a
particular piece of software, and while the "afs" in the mainstream Linux
kernels speaks some of the same protocols, it is not OpenAFS. In
particular, it shares virtually no code with OpenAFS, and its integration
model is somewhat different.
At the moment, there is no support for compiling OpenAFS into the kernel;
it is intended to be loaded as a module. In fact, I don't believe the
kernel build system supports compiling in "external" modules that are
maintained outside the kernel tree.
That said, I'm reasonable certain that, with a sufficient understanding of
the kbuild architecture, you could hack something together that would allow
you to compile OpenAFS into the kernel. A good place to start would be the
kbuild documentation in Documentation/kbuild (in the Linux kernel source).
I would not be surprised if a patch supporting this in a clean way were
accepted into OpenAFS. I'm not sure exactly what "a clean way" would be,
but I'd expect it to involve a make target that produced a file or
directory tree to be added to the kernel source before building a kernel.
The other thing you could look into, if you have some lattitude to
interpret your security policy, would be to investigate the signed-module
patches. This approach would allow you to build a kernel which loads only
modules cryptographically signed by an authorized key.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA