<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 7, 2014 at 8:18 PM, Ben Langmuir <span dir="ltr"><<a href="mailto:blangmuir@apple.com" target="_blank">blangmuir@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>On Feb 7, 2014, at 11:03 AM, Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:</div>
<blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div><div><font color="#000000">...</font></div></div></div></div></div></blockquote><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>I'd vote for making that an explicit goal; two reasons:</div><div>1. I don't think it'll make a first iteration harder to implement</div>


<div>2. saying that we'll do things like that later will almost certainly make it super-hard to do later</div><div><br></div><div>For us, the ability to have virtual file buffers that do not exist on disk is one of the core requirements we have for all our tools; I think in a more and more network-based world this will also become more necessary in general in the future.</div>

</div></div></div></blockquote><div><br></div></div><div>How do you imagine changing clients that currently expect to be able to get a file descriptor?  Do you remove that concept and provide only higher-level APIs, like “getBuffer” and “getRawOstream”, or create some opaque file descriptor that can be returned from openFileForReading and openFileForWriting?  The latter seems like it doesn’t need to be built in from the start, since we can continue to have the usual file descriptor APIs, and update clients later when we change what a file descriptor is.  That’s what I was imagining, but you may have a better idea.  Also, even if adding fully virtual files doesn’t make a first iteration harder to implement, what about testing it?</div>

</div></blockquote><div><br></div><div>Well, that's an interesting question :) So, do you want a virtual file system that we can plug below the file manager pretty much "as-is", and it just works? In that case, I'd guess we need to do the latter. I'm also not sure which clients we might be able to convert later.</div>

<div><br></div><div>If you don't want to provide a vfs below the file manager, where do you want to use it? Currently, all Tooling/ stuff relies on being able to use the file overlaying logic to inject into PPOptions / SourceManager / FileManager to allow (nearly) fully file system independent replays of compilations. Would you propose to break this behavior as part of the transition?</div>
</div></div></div></div></blockquote><div><br></div><div>I definitely want to put this below the FileManager.  FileManager would just keep a reference to an AbstractFileSystem (although I’m not sure who should actually own that object), that we use to represent the ‘unified’ file system and do all of its operations through it.  Any existing uses of FileManager should continue to work as-is.  This way we can phase in the VFS without changing the way overriding files works now.</div>
</div></div></blockquote><div><br></div><div>Sounds good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im">
<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">One implementation of the AbstractFileSystem interface would be a wrapper over the ‘real’ file system, which would just defer to llvm::sys::fs.<div>



<div><br></div><div><span style="white-space:pre-wrap"> </span>class RealFileSystem : public AbstractFileSystem { … };</div><div><br></div><div>And to provide a unified view of the file system, we can create an overlay file system, similar to [1].</div>



<div><br></div><div><span style="white-space:pre-wrap"> </span>class OverlayFileSystem : public AbstractFileSystem { … };</div><div><br></div><div>To support a build system providing clang with a virtual file layout, we could add an option to clang that accepts a file describing the layout of a virtual file system.  In a first iteration, this could be a simple json file describing the mapping from virtual paths to real paths, and a corresponding class VFSFromJSONFile : public AbstractFileSystem.  Later we can evolve a more efficient binary format for this.  In addition we should provide functions in libclang to produce these files.</div>


</div></div></blockquote><div><br></div><div>The rest sounds generally good.</div><div><br></div><div>One concern I have that has not been brought up is the old problem of making file operations relative to a directory entry that is taken once at the start of an operation (imagine starting a compilation from a symlinked directory, and somebody changing the link). I think this will probably not a goal for phase 1, but would be nice if we could keep it in the back of our heads ;)</div>

</div></div></div></blockquote><div><br></div></div><div>Can you expand on this? Dumb question: why can’t we just ask the OS for a canonical path and work from that?</div></div></blockquote><div><br></div><div>The main problem is less whether the path is canonical than that an unrelated happenstance in the file system might lead to inconsistencies in a compile step.</div>

<div><br></div><div>Imagine a source tree in src-head and one in src-branch.</div><div>$ ln -s src-head src</div><div>$ cd src</div><div>$ clang <a href="http://file.cc" target="_blank">file.cc</a> &</div><div>$ cd ..</div>
<div>$ rm src</div><div>$ ln -s src-branch src </div>
<div><br></div><div>Now if the clang process takes a while to run and resolves files it opens via "absolute" paths rather than relative to the current working dir file entry, it can see inconsistent state (for example, get a header from src-branch instead of from src-head).</div>

<div><br></div></div></div></div></blockquote><div><br></div></div><div>Hmm, haven’t thought about this one.  I guess I agree this is not a near-term goal :)</div></div></div></blockquote><div><br></div><div>I'd like to consider it design-wise at least on a straw-man level (to be shot down ;)</div>
<div><br></div><div>If we want to support this in the future, it might affect both the ownership and the API design question. For example, one design straw-man would be to have interfaces for FileSystem, Directory and File, where FileSystem can give you Directory's and those again can give you Files. That would trivially support using directory-entry based OS interfaces where they are available, but would mean more code overhead per FileSystem implementation.</div>
<div><br></div><div>A different approach would be to use descriptors for files and directories, and have only a single FileSystem interface that can handle the instances. Seems slightly less "nice" from a user point of view, but potentially simpler and less overhead for the implementation.</div>
<div><br></div><div>From the other mails in this thread it sounds to me more like you want to basically punt on those questions and just provide the interface and access methods to get buffers for files. That might also be fine for now, but I'd prefer if it is a conscious decision rather than an accidental one :)</div>
<div><br></div><div>Cheers,</div><div>/Manuel</div></div></div></div>