[PATCH] Some infrastructure work for virtual file system (now on phab)

[Argyrios Kyrtzidis]

On Feb 14, 2014, at 9:42 AM, Manuel Klimek <klimek at google.com> wrote:

> On Fri, Feb 14, 2014 at 6:40 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
> 
> On Feb 14, 2014, at 9:26 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> >> So you’re suggesting something like this:
> >>
> >> class AbstactFileSystem {
> >> …
> >>  class FileDescriptor {
> >>  public:
> >>    virtual ErrorOr<Status> status() = 0;
> >>    virtual error_code getBuffer(…) = 0;
> >>    virtual error_code close() = 0;
> >>  };
> >> ...
> >> };
> >
> > That looks odd. If we can keep it to one virtual interface (like in
> > the patch) that would probably be better. On llvm a file descriptor in
> > always an int. There is some desire to use a file handles on windows,
> > but that is also just a abstract pointer.
> >
> > Can't we make the file handle an arbitrary uintptr_t sized object? The
> > FileSystem is then able to interpret it in any way it wants.
> 
> I find it natural, the file descriptor encapsulates the file operations that you perform on a “file entity” (which can be a virtual file or whatever) and this is what we are modeling.
> 
> I would find it unnatural that you have a series of multiplexed AbstractFileSystem objects and you constantly have to thread through them uintptr_t's that every AFS object has to say whether it understands that particular uintptr_t or not.
> it could be complicated to have them cooperating on the interpretation of the uintptr_t.
> 
> Why wouldn't a multi-plexing AbstractFileSystem implementation exactly know which FDs go to which one of its file system operations? A non-multi-plexing implementation could then just assert the FD is one of its own.
> It feels rather natural to me that if you have multiple layers of implementations that make up a "tree" of file systems, a request would go through all the layers until landing at the lowest one...


The “get a file descriptor object” will land on the appropriate AFS which will return a proper implementation to do file operations on.

There is no significant difference on the client side (instead of calling a method on the AFS, it calls a method on the FileDescriptor), it may simplify a bit some functions to just accept a FileDescriptor if they only need such a thing (instead of always passing an AFS + FD), and the multiplex implementation becomes simpler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140214/adb40831/attachment.html>