api: add atomfs mount/umount APIs #256
                
     Merged
            
            
          
  Add this suggestion to a batch that can be applied as a single commit.
  This suggestion is invalid because no changes were made to the code.
  Suggestions cannot be applied while the pull request is closed.
  Suggestions cannot be applied while viewing a subset of changes.
  Only one suggestion per line can be applied in a batch.
  Add this suggestion to a batch that can be applied as a single commit.
  Applying suggestions on deleted lines is not supported.
  You must change the existing code in this line in order to create a valid suggestion.
  Outdated suggestions cannot be applied.
  This suggestion has been applied or marked resolved.
  Suggestions cannot be applied from pending reviews.
  Suggestions cannot be applied on multi-line comments.
  Suggestions cannot be applied while the pull request is queued to merge.
  Suggestion cannot be applied right now. Please check back later.
  
    
  
    
This code is somewhat imported from https://github.com/anuvu/atomfs, with
heavy modification (and some bug fixes) to support the new mount structure
with a verity device in the middle.
The idea here is that the Umount() function should be able to parse the
mountinfo entry and walk back and destroy things as necessary (being
careful not to destroy things that are in use by other atomfs things
entries). This gets kind of tricky because there is no namespace for
devicemapper or the loopback driver and thus the associated devices are
global resources that must be accounted for.
Finally, there are two unsafe FIXMEs introduced in this commit when we
decide to re-use a mountpoint or block dev. In these cases we should ask
the kernel what root hash it has for a block dev, however APIs for this are
still pending, so this patch is "incomplete" for now, but has a sketch of
where the checks would go (and I hope to merge it as-is and continue work
on these APIs).
Additionally, patch necessitated fair amount of new APIs for our
dependences, some of which have been merged upstream and some of which are
still pending, hence the additional replace directives.
Signed-off-by: Tycho Andersen tycho@tycho.pizza