[OpenAFS-devel] Unix cm architecture (and usermode unix client)

Andrew Deason adeason@sinenomine.net
Wed, 07 Jan 2009 21:00:52 -0500


RT #124093 has a preliminary patch for a port of the Unix cache manager
to libuafs and FUSE (basically, a Unix client that's entirely in
userspace). The implementation is a bit ugly at the moment, though, some
of which is due to the way the unix client is structured. So, I wanted
to discuss it a bit here before trying to do any drastic changes to afsd
or libuafs; the changes in #124093 to afsd.c may help illustrate what
problem I'm trying to solve, here.

In short, my issue with the unix client is that the initialization code
for both afsd (mainproc) and libuafs (uafs_Init) do almost exactly the
same thing, except that the libuafs code is outdated (they calculate cm
parameters based off of given parameters and defaults, and make certain
AFS-specific syscalls in a certain order). Since this is essentially the
same code in two places, bugs tend to appear when something needs to be
changed, and nobody remembers that the libuafs equivalent needs to be
changed as well (what I expect caused #104699 and #104698).

There's also a few namespace collisions with some variables and
functions between afsd and either libuafs itself, or the generic kernel
code. Which is just plain annoying.

What #124093 does is just not declare such variables/functions in the
UKERNEL case (ugh), and uses afsd's mainproc() basically as a
replacement for libuafs's uafs_Init(), and entirely ignores the latter.
Now, ignoring uafs_Init() works for this particular case, but getting
rid of it completely would mean that libuafs becomes essentially useless
to any code that wants to use it, unless it provides it's own
implementation of afsd.

So, what I'd think would be best is if most of the current afsd code
would be moved out into some library (I have no idea if any of the
current ones make sense, or if an entirely new one should be created),
that both afsd and libuafs can use. A usermode client could then just be
an entirely separate standalone program, that just calls libuafs stuff.

Thoughts? Am I making sense?

-- 
Andrew Deason
adeason@sinenomine.net