various diagrams
[openafs-wiki.git] / CacheManagerPorting.mdwn
1 -- Matt Benjamin - 05 Apr 2010
2
3 The following notes were directed to a potential GSOC participant interested in
4 porting the [[OpenAFS]] cache manager to [[NetBSD]]. There are some remarks
5 specific to [[NetBSD]], and there's a lack of a high-level view of the ancestry
6 of different ports and phases of work, that I think might be useful, among
7 other things.
8
9 1. yes, I do have a partial port to [[NetBSD]], based on the [[OpenBSD]] port.
10 It turns out that the [[NetBSD]] port was the original ancestor port of
11 [[OpenBSD]] and possibly influenced our [[FreeBSD]] port, too. Hence it has a
12 good deal in common with several other ports, but may agree more closely in
13 some areas, such as VM integtration.
14
15 2. My port isn't fully viable. Where it might be useful is as a fairly large
16 bucket of copy-paste first-cut solutions to many issues.<br /><br
17 />Specifically, an [[OpenAFS]] cache manager can be thought of as a collection
18 of cooperating subsystems and internal interface mappings covering a finite set
19 of features. The main body of that platform-specific mapping glue is localized
20 in the various port-specific osi\_\* files (e.g., OBSD/osi\_\*), especially
21 osi\_machdep.h, osi\_vnodeops.c, and osi\_file.c.
22
23 Of course, there are parts scattered around, including under
24 rx/&lt;PLATFORM&gt;, rx\_knet.\{h,c\}, in VNOPS, in afs\_pioctl.c, and
25 elsewhere.<br /><br />One way I would talk about milestones would be to talk
26 about different levels:<br /><br />1\. complete and reviewed candidate
27 implementations of all the applicable subsystem mappings for a port, taken to a
28 state of compilation but not yet integration tested. Here, you have "solutions"
29 for a bunch of point problems, including (I'm certainly leaving out some):
30
31 1. internal locking (how glock and subsystem/object locks are implemented)
32 2. memory allocation (the local KMALLOC often)
33 3. UDP socket communications
34 4. a UFS-cognate cache (dcache), if present
35 5. syscall interface conventions
36 6. kernel-to-user memory space issues (UIO\_SYSSPACE, etc, or similar, on a BSD, etc)
37 7. implementing the local kernel file system interface, e.g., VFS
38 8. platform-specific credential handling, where applicable--here, it's [[NetBSD]]'s kauth system
39 9. module conventions--I used lkms, and that's probably desireable, but for [[NetBSD]], we might have a cognate build that uses RUMP--creating a userland cache manager that might be easier to debug
40 10. miscellaneous bits, such as as processes/threads/time
41
42 If I were planning formally to complete a project from this point, I might start with the following:<br /><br />1\. plan for integrating or re designing all the mappings already supplied in my candidate port<br />2\. review of module build, possible plan and build RUMP port<br />3\. milestone to load and mount /afs for the first time in a workstation cell<br />4\. milestone to perform a sequence of point operations successfully, in some sequence:<br />4\.a. access file and directory metadata in a local cell for simple cases (ignore some VFS locking cases, ignore potential issues with vnode recycling)<br />4\.b. execute a suite of read-write operations on files, simple cases, without credentials (system:anyuser perms)<br />4\.c. milestone to execute through 4.b. with successful unmount of /afs<br />4\.d. implement/test token setting operations and repeat 4.b.<br />4\.e. milestone to implement PAG (process-authentication group) support--raw group manipulation -should- work, but on [[NetBSD]] a kauth listener could be implemented (or deferred for later)<br />4\.f. milestone to successfully execute a richer suite of filesystem tests (probably fsx) and collect meaningful benchmarks
43
44 4.g dynroot
45
46 I'm pretty certain that this is a lot to do in a GSOC project, and I may have left things out . However, some work has been done, and, a viable project might be to do a significant subset.