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 [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
