marks version

git-svn-id: svn+ssh://svn-nitpicker.cl.cam.ac.uk/linpicker/trunk@79 88473608-6f18-0410-8b6c-91216bd3049c

1 files changed, 46 insertions, 0 deletions

diff --git a/README b/README
new file mode 100644
index 0000000..60f960c
--- /dev/null
+++ b/README
@@ -0,0 +1,46 @@
+This is "Linpicker", a Linux version of Nitpicker.
+As much code as possible was copied from the Nitpicker implementation,
+so the same license (GNU GPL) applies.
+
+Nitpicker's implementation is deeply married to L4; trying to get its
+incredibly baroque build environment and tools (esp. the DICE CORBA compiler)
+working took enormous amounts of time, even with the start of a Linux
+implementation.  That start turned out to be painful; it presumed that
+UDP packets are never dropped (but they are!), that UDP port numbers have
+same properties as local thread ids (but they don't!), and so on.
+It was also deeply unsuitable for real security; Nitpicker itself was small,
+but all the code it deeply depended on turned out to be a massive
+infrastructure that "had" to come with it.  Not only would that be hard
+to validate for security - it was clear that it was NOT secure (against
+buffer overflows, denial-of-service attacks, and so on).
+Nitpicker's DICE compiler was particularly troublesome; it generated code
+that was unsuitable, so you ended up having to edit generated (code).
+DICE is specifically designed to be an "IDL kernel for L4 micro-kernels",
+as it clearly states on its web page... woe to those who don't use L4.
+In theory you could modify DICE, but DICE was absurdly complex (an example
+of how with enough method calls you can obscure any functionality).
+The build environment depended on virtual paths, which ONLY make could see...
+so all other tools (e.g., ctags, grep, etc.) were nearly useless,
+since any search would find multiple instances of files.
+
+So this re-implements Nitpicker, but with the KISS notion.
+SIMPLICITY is the goal here, with small amounts of code.
+
+I thought about using an existing ORB (like ORBit), but that'd have the
+same problem as DICE: Lots of code that we can't depend on.  Since we must
+port to Xen (on grant tables, etc.), and nearly all CORBA functionality
+is unneeded, it was easier to write a tiny comm structure ourselves.
+
+Phil Dollery came up with the name "Linpicker"; David A. Wheeler
+confirmed on Apr 20, 2007 that Google found no hits for the name.
+
+Not trying to be CORBA (or DCE) compliant.  See:
+"The Rise and Fall of CORBA" by Michi Henning, ZeroC
+
+The comm structure has the goals of:
+* Very simple tool implementation
+* Very simple resulting code (easily examined)
+* Robust against malicious clients: clients may drop partway through,
+  send excessive or insufficient data, or send "wrong" messages.
+
+