search for: cachingfilesystem

...lower level VFS > layer that is rich enough to support everything we do and the vagaries > of Win32/Unix, but is otherwise minimal. What about FileManager is too high level / too clang specific? The uniquing logic? The possibility to add in stats caches? Do you think we'd want to have a CachingFileSystem on top of the VFS layer? That would sound more orthogonal, on the other hand FileManager is doing pretty OS-specific stuff to unique the inodes where possible. > One requirement I hope any proposed VFS design will support is > emulating Win32 on Unix (and vice versa), which imposes assorted...

...ayer that is rich enough to support everything we do and the vagaries >> of Win32/Unix, but is otherwise minimal. > > What about FileManager is too high level / too clang specific? The > uniquing logic? The possibility to add in stats caches? > Do you think we'd want to have a CachingFileSystem on top of the VFS > layer? That would sound more orthogonal, on the other hand FileManager > is doing pretty OS-specific stuff to unique the inodes where possible. I guess I was thinking that it might be more cumbersome to move the other parts of LLVM / Clang that do direct file access to us...

Hi Manual, I'm +2 on the general idea. I have had various thoughts in this direction as well (although no implementation). See: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-July/009903.html for my RFC from last year (focused at bug reporting, but involved defining a VFS layer). My one main implementation level comment is I don't think FileManager is the right API layer to abstract

Hi, while working on tooling on top of clang/llvm we found the file system abstractions in clang/llvm to be one of the points that could be nicer to integrate with. I’m writing this mail to propose a strawman and get some feedback on what you guys think the right way forward is (or whether we should just leave things as they are). First, the FileManager we have in clang has helped us a lot for