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

[Manuel Klimek]

On Fri, Feb 14, 2014 at 9:11 PM, Ben Langmuir <blangmuir at apple.com> wrote:

>
> 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.
>

Yea, I can see why you dislike it - I don't have a much better name, and
Real doesn't sound too bad (I guess most people would intuitively consider
it "the file system of the current OS", so it seems fine).


> 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?
>

I like it.


>
> 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/22650d38/attachment.html>