[OpenAFS] Re: [OpenAFS-devel] interface for vos split

[Jeffrey Hutzelman]

--On Thursday, January 08, 2009 12:32:20 PM -0800 Russ Allbery 
<rra@stanford.edu> wrote:

> "Steven Jenkins" <steven.jenkins@gmail.com> writes:
>
>> fs getfid (like virtually all of the fs subcommands) is implemented by
>> marshalling arguments and then making a PIOCTL call into the kernel.
>> Without a cache manager, you can't get a response to that PIOCTL.  Even
>> with a cache manager running, you would need to marshal up the arguments
>> and make a PIOCTL, which means linking vos.c in with new libraries.  vos
>> is already huge; I think making it understand how to do PIOCTL calls
>> would be significant enough to where we would look at getting rid of fs
>> entirely (i.e., if vos can do one PIOCTL, adding the rest is relatively
>> straightforward).
>
> These are all reasonable arguments from a code perspective

Except, of course, that vos already depends on libsys, and already contains 
the (relatively trivial) code required to make AFS system calls, including 
pioctl.  The additional code required to call VIOCGETFID is something like 
half a dozen lines:

struct ViceIoctl blob;
struct VenusFid fid;
blob.out = &blob;
blob.out_size = sizeof(blob);
blob.in_size = 0;
pioctl(path, VIOCGETFID, &blob, 1);


>> Thus it seems to me most straightforward from a user-experience
>> viewpoint to require the vnode.

Straightforward, but difficult to use.  Vnode numbers are an implementation 
detail that we should not depend on making visible to users.


> aI think
> the above would be less confusing than an implementation that sort of
> supports directory names but doesn't in a way that users expect.

Agree