Create a bootstat library for external C and C++ programs

README

Index: README
diff --git a/README b/README
index 6a3d0a074d955ec2330278d21b7114f051d86aa4..787e5f0ebf405ce2c0d56eb7007b6e1cab822da1 100644
--- a/README
+++ b/README
@@ -15,13 +15,17 @@ Summary:  The command gathers and records the contents of
 not the boot partition), and associates the data with the passed
 in <event-name>.
 
-==== Design details and API
+==== API specification
+The C and C++ API is defined in "bootstat.h".  See that header for
+specification details.
+
+==== Design and implementation details
 Uptime data are stored in a file named /tmp/uptime-<event-name>;
 disk statistics are stored in a file named /tmp/disk-<event-name>.
-This file naming convention is a concession to existing code that
-depends on these files existing with these specific names, including
-the platform_BootPerf test in autotest, /etc/boot-complete.conf, and
-portions of Chrome.
+This convention is a concession to pre-existing code that depends on
+these files existing with these specific names, including the
+platform_BootPerf test in autotest, the boot-complete upstart job,
+and the Chrome code to report boot time on the login screen.
 
 New code should treat the file names as an implementation detail,
 not as the interface.  You should not add new code that depends on
@@ -29,12 +33,14 @@ the file names; instead, you should enhance the bootstat command
 and/or library to provide access to the data you need.
 
 ==== Code conventions
-This is currently C code, because a) the code is intended for use
-as a library accessible to C and C++ code, and b) it's too small to
-make sense using C++ features.  However, if the program grows, it
-may be appropriate to convert all or part to C++.
-
-To the extent that the code should be acceptable to a C++ compiler,
-it should also adhere to Google's C++ coding conventions.  In areas
-where the code is C specific, use your best judgement (note that
-Google also has Objective-C coding conventions that may be useful).
+This is currently C code, because a) the code is required for use
+as a library accessible to both C and C++ code, and b) it's too
+small to justify the boilerplate required to have separate C and
+C++ bindings.  However, if the program grows, it may be appropriate
+to convert all or part to C++.
+
+To the extent that the code can be acceptable both to C and C++
+compilers, it should also adhere to Google's C++ coding conventions.
+In areas where the code is C specific, use your best judgement (note
+that Google also has Objective-C coding conventions that may be
+useful).