From: ezk <ezk>
Date: Mon, 18 Apr 2022 17:18:42 +0000 (+0000)
Subject: CSE506 project notes
X-Git-Url: https://git.fsl.cs.sunysb.edu/?a=commitdiff_plain;h=refs%2Fheads%2Forigin;p=wrapfs-mgmt.git

CSE506 project notes
---

diff --git a/2022-04-18-notes.txt b/2022-04-18-notes.txt
new file mode 100644
index 0000000..0ff6b10
--- /dev/null
+++ b/2022-04-18-notes.txt
@@ -0,0 +1,118 @@
+Git branches, remotes, and merges
+
+Git: append-only system
+
+Git: O1, O2, O3, O4
+- each is appended on top of another
+- each object (commit) has a unique hash
+- top/latest object is "head" (for each branch)
+- you can have branches that share a subset of objects, and deviate
+- you can delete branches, which'd delete only ITS unique objects
+- you cannot insert an object below an existing one
+
+- you can pop/delete top N objects, then insert new one, then re-add
+  and recommit the ones you've popped. but that will change the head!
+
+* Linus:
+
+... a kernel is released
+linus opens up a "merge window" (2-3 weeks)
+- all queue patches that add features or make major bug fixes are added
+- these are already vetted and reasonably tested patches from well known ppl
+- close merge window, no more new features
+- then they go into 7-8 release cycles (RC1..RC8), lasting ~3 months
+- in RCn, you only do testing, regressions, and fix bugs
+- linus calls the current head 5.18 (meaning .0)
+
+repeat: new merge window, RCn, then next 5.X+1
+
+L1, L2, L3, .... , Ln [tag "5.18-RC3", .... Lm [5.18 "official"]
+
+* Greg KH: maintains the stable trees
+
+Clone Linus's tree at major release points, like the head corresponding to
+5.18
+
+- release bug fixes to 5.18, making it 5.18.1, 5.18.2, etc.
+- only bug fixes and any emergency security fixes
+- creates a de-facto branch off of Linus's tree
+
+* Wrapfs
+
+out of tree code
+
+I have a wrapfs git tree for every stable version: wrapfs-5.4, wrapfs-5.3,
+...
+- and also for linus's version, called wrapfs-latest
+In each tree, there are
+1. a "master" branch that corresponds to Linus's or Greg's trees.  This is a
+   copy (clone) of all their tree's objects, locally stored on FSL's git
+   server (git.fsl.cs.sunysb.edu).
+2. a added "remote" configured in .git/config, which points to the source
+   (linus or greg where THIS tree was cloned from)
+3. a "wrapfs" branch, which adds wrapfs code patches relative to "master".
+
+Users outside FSL, who just want to get wrapfs for kernel version X,
+- git clone from git://git.fsl.cs.sunysb.edu/scm/git/wrapfs-5.4.y.git
+- if they already cloned before, they just need to
+git pull
+- switch to branch wrapfs
+- recompile
+
+Developers:
+
+1. check what the wrapfs branch adds on top of mainline kernel using
+$ git diff master wrapfs
+- useful to see that we don't touch code we're not suppose to
+- I also release patches as a .diff that people can apply
+
+2. we develop in the wrapfs branch, in a tree cloned locally
+- make sure that you don't commit+push code to wrapfs branch unless it's
+  stable
+- better: each student/developer has their own "dev" branch called user-name
+	If you do this, you can eventually merge tested patches from an
+	"unstable" branch to a stable one, ready for "release"
+
+3. How to perform period maintenance, say on Greg's tree
+wrapfs-5.4 git tree as synced w/ greg's 5.4.3 ("head -4 Makefile")
+- greg is now at 5.4.189
+- stable branch patches are unlikely to break wrapfs
+(a) in the wrpfs-5.4 tree, we switch to master branch
+(b) do a git pull not from default "origin" but from "korg" remote
+(c) merge master tree onto wrapfs tree
+- this'll try to add all of the just downloaded master branch changes, into
+wrapfs
+- if git merge fails, you have to figure out why and fix
+- if merge succeeded, then we can recompile the kernel and run some testing
+  to ensure wrapfs still works
+(d) when testing succeeds, then we can push to default remote ("origin")
+    which is FSL git repo.
+
+TBD:
+- how to handle Linus's tree (roughly the same as GKH's tree)
+- my latest wrapfs release 5.4, which means wrapfs-latest tracked 5.4-RCx
+- Linus is now working on 5.18-RCx
+- I'm missing "stable" wrapfs branches b/t 5.5 and 5.17, inclusive
+- this needs more work, b/c those are newer kernels, with possibly changes
+  to VFS that would break wrapfs
+
+If we're lucky, wrapfs won't compile and we can go see what's
+changed.
+
+Worse: it compiles, but there's a subtle semantic change.
+
+For that we try to find out what has changed in (1) VFS or (2) ecryptfs (a
+stackable crypto f/s).  I use "git diff fs/ecryptfs FROM TO" or the like to
+find out which patches between my version and the latest kernel version I'm
+interested (FROM..TO) have changed anything in some/path.  This is sometimes
+called a "git blame".
+
+* helper scripts
+
+in CVS: repo named "wrapfs" in cvs.fsl.cs.sunysb.edu:/scm/cvsroot
+
+* Testing
+
+used to run Linux Test Project (LTP), then "xfstests"
+- often most bugs are found with a simpler tool called "racer".
+