[OpenAFS-devel] unix afsd organization

Andrew Deason adeason@sinenomine.net
Wed, 17 Jun 2009 14:33:47 -0500


RT 124947 [1] has a patch for splitting up afsd into a kind of backend
and frontend of sorts. The "backend" is all of the logic of command-line
parsing, and issuing afs syscalls, and a few other things. The
"frontend", of which now there's only one but there could be many,
consists of code that's very specific to using the afs kernel module
client: how syscalls are made, mounting /afs, etc. This division allows
for easily swapping out the code for kernel module with, say, the
userspace kernel code.

Most of the patch is just moving some code from afsd.c to afsd_kernel.c.
However, there is the addition of an interface between the frontend and
backend afsd code. The code in 124947 uses an interface that looks like
this (more comments are in the actual patch):

typedef void (*afsd_mount_func)(const char*, const char*);
typedef int (*afsd_syscall_func)();

struct afsd_init_opts {
  /* 1 to turn on AFS_CACHE_VNODE_PATH code, 0 otherwise */
  afs_uint32 cache_vnode_path;

  afsd_mount_func mount_afs;
  afsd_syscall_func call_syscall;
  afsd_syscall_func fork_syscall;
  afsd_syscall_func fork_syscall_rx;
};

void afsd_init(const struct afsd_init_opts *opts);
int afsd_run(int argc, char **argv);

So, the idea is, the kernel frontend specifies callbacks for issuing the
mount() call for AFS, and for issuing syscalls.

The kernel-based frontend would just have a main() that consists of a
call to afsd_init and afsd_run. Other userspace stuff could have very
different-looking entry points (inside other applications, browser
plugins, etc etc).

Any comments or criticisms of this interface, or anything to help move
this forward would be appreciated.

[1] https://rt.central.org/rt/Ticket/Display.html?id=124947

-- 
Andrew Deason
adeason@sinenomine.net