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

Ben Langmuir blangmuir at apple.com
Fri Feb 14 12:11:43 PST 2014


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

> On Fri, Feb 14, 2014 at 7:56 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
> 
> On Feb 14, 2014, at 10:49 AM, Ben Langmuir <blangmuir at apple.com> wrote:
> 
> >
> > On Feb 14, 2014, at 10:14 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> >
> >>> 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.
> >>
> >> The only issue I have with it is that code using the virtual fs then
> >> becomes quiet a bit different from code that is not using it. Code not
> >> using it has a FD that is a simple POD that is copied by value. Code
> >> using the virtual fs has a much more complex object that needs to be
> >> passed by pointer.
> >
> > I felt the same way originally, but these are both cases of passing by reference since the int is just a handle to a more complex object inside the operating system :)  The syntax of method calls is obviously very different though.
> >
> >>
> >> A filesystem could even use a virtual FD implementation if it wanted
> >> to. Just make the FD it receives an index into a table. That way using
> >> a virtual file per file object is an implementation detail of that
> >> file system.
> >>
> >> In the end, I guess it is a question of preference. Since I have no
> >> better objections than "it looks odd", it is fine to go that way if
> >> people actually using the feature prefer it. Maybe then just call it a
> >> FileObject instead of a FileDescriptor to avoid confusion with the
> >> simple ints we are used to?
> >
> > Good point, any objections to just calling it ‘File’?
> 
> This seems too generic, maybe ‘AbstractFile’ ?
> 
> When we are at naming, I'll take the liberty to make a very different proposal:
> File, FileSystem for the interfaces, LocalFile / LocalFileSystem instead of RealFileSystem for the standard implementation. I personally dislike Abstract or Interface in the names, as it distracts from the rest of the name (but I fully understand that this is more taste than a real concern ;)

The one think I liked about Abstract is it warns you not to assume this is the real file system, so I’ll use a namespace ‘vfs’.  I dislike Local, as it implies ‘not over a network file system’ to me. Here’s what I now hate the least:

namespace vfs { // replace Abstract
class Status; // hoist to save typing
class File;
class FileSystem;
class RealFile;
class RealFileSystem;
}

Any *strong* objections?

Ben

>  
> 
> >
> > Ben
> >
> >>
> >> Cheers,
> >> Rafael
> >
> >
> >
> > _______________________________________________
> > cfe-commits mailing list
> > cfe-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140214/80e1afa4/attachment.html>


More information about the cfe-commits mailing list