--On Thursday, January 08, 2009 12:32:20 PM -0800 Russ Allbery
<[email protected]> wrote:
"Steven Jenkins" <[email protected]> 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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
