[cfe-dev] "devirtualizing" files in the VFS

[Whisperity via cfe-dev]

The contract of the VFS was a tree of "directories" containing "files" that
you can access via providing a "path" and getting a "char buffer" with
content. Noone ever said that any of these "files" have any sort of
semblance on the "real drives". That's what ~~clang~~ llvm::fs::getRealFS()
was about, giving you a VFS that bridged back to the real deal.

If some client code puts effort into properly mounting up Clang's standard
library files into memory or their own VFS impl --- or only allows usage of
code that does *NOT* use the standard library *AT ALL* --- then the
frontend can go through without every touching, or even seeing, the realFS
at all.


Sam McCall <sammccall at google.com> ezt írta (időpont: 2018. nov. 27., K,
19:52):

> On Tue, Nov 27, 2018 at 7:01 PM Jonas Devlieghere <jdevlieghere at apple.com>
> wrote:
>
>> Hi Sam,
>>
>> Does extending the status with a path sound reasonable? This would work
>> similar to the current Name field, which is controlled by UseExternalName.
>>
>> Please let me know what you think.
>>
>> Thanks,
>> Jonas
>>
>
> Design-wise, adding a second Name field to Status doesn't seem
> significantly different than adding a "getOtherName" field to VFS.
> I don't think it's really reasonable to have this in the VFS interfaces,
> because using it in any way means you're coupled to particular
> implementations.
>
> Implementation-wise, it seems the only way to do that would be to add an
> extra string to Status, and some applications probably keep a lot of Status
> objects. So it doesn't seem like an improvement vs the VFS method.
>
> Overall I think if LLDB wants to wants to break abstraction and use the
> native filesystem sometimes, it should have concrete private
> implementations with wider interfaces, and bridge to common code by having
> them implement the VFS interfaces. The contract of VFS may have been "real
> filesystem with some redirected files", but I don't think it has been for
> several years, and people rely on this.
>
> I'm not an owner here though. I don't really know how these decisions get
> made, and would like to hear more opinions.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181128/a96290cd/attachment.html>