-- Matt Benjamin - 05 Apr 2010
-The following notes were directed to a potential GSOC participant interested in porting the [[OpenAFS]] cache manager to [[NetBSD]]. There are some remarks specific to [[NetBSD]], and there's a lack of a high-level view of the ancestry of different ports and phases of work, that I think might be useful, among other things.
+The following notes were directed to a potential GSOC participant interested in
+porting the [[OpenAFS]] cache manager to [[NetBSD]]. There are some remarks
+specific to [[NetBSD]], and there's a lack of a high-level view of the ancestry
+of different ports and phases of work, that I think might be useful, among
+other things.
-1. yes, I do have a partial port to [[NetBSD]], based on the [[OpenBSD]] port. It turns out that the [[NetBSD]] port was the original ancestor port of [[OpenBSD]] and possibly influenced our [[FreeBSD]] port, too. Hence it has a good deal in common with several other ports, but may agree more closely in some areas, such as VM integtration.
+1. yes, I do have a partial port to [[NetBSD]], based on the [[OpenBSD]] port.
+It turns out that the [[NetBSD]] port was the original ancestor port of
+[[OpenBSD]] and possibly influenced our [[FreeBSD]] port, too. Hence it has a
+good deal in common with several other ports, but may agree more closely in
+some areas, such as VM integtration.
-2. My port isn't fully viable. Where it might be useful is as a fairly large bucket of copy-paste first-cut solutions to many issues.<br /><br />Specifically, an [[OpenAFS]] cache manager can be thought of as a collection of cooperating subsystems and internal interface mappings covering a finite set of features. The main body of that platform-specific mapping glue is localized in the various port-specific osi\_\* files (e.g., OBSD/osi\_\*), especially osi\_machdep.h, osi\_vnodeops.c, and osi\_file.c. <a href="http://escort-models.com/">проститутки</a> Of course, there are parts scattered around, including under rx/<PLATFORM>, rx\_knet.\{h,c\}, in VNOPS, in afs\_pioctl.c, and elsewhere.<br /><br />One way I would talk about milestones would be to talk about different levels:<br /><br />1\. complete and reviewed candidate implementations of all the applicable subsystem mappings for a port, taken to a state of compilation but not yet integration tested. Here, you have "solutions" for a bunch of point problems, including (I'm certainly leaving out some):
+2. My port isn't fully viable. Where it might be useful is as a fairly large
+bucket of copy-paste first-cut solutions to many issues.<br /><br
+/>Specifically, an [[OpenAFS]] cache manager can be thought of as a collection
+of cooperating subsystems and internal interface mappings covering a finite set
+of features. The main body of that platform-specific mapping glue is localized
+in the various port-specific osi\_\* files (e.g., OBSD/osi\_\*), especially
+osi\_machdep.h, osi\_vnodeops.c, and osi\_file.c.
+
+Of course, there are parts scattered around, including under
+rx/<PLATFORM>, rx\_knet.\{h,c\}, in VNOPS, in afs\_pioctl.c, and
+elsewhere.<br /><br />One way I would talk about milestones would be to talk
+about different levels:<br /><br />1\. complete and reviewed candidate
+implementations of all the applicable subsystem mappings for a port, taken to a
+state of compilation but not yet integration tested. Here, you have "solutions"
+for a bunch of point problems, including (I'm certainly leaving out some):
1. internal locking (how glock and subsystem/object locks are implemented)
2. memory allocation (the local KMALLOC often)
git://git.openafs.org / openafs-wiki.git / blobdiff