On 5/18/2011 9:14 PM, Derrick Brashear wrote:
basically you have some number of "slots" in the parm array which are
the switches. all this does is skip to a fixed offset before the next
AddParm is processed and thus fills a slot in the array.
so the assumption here is no command has more than 12 of its own
parameters, and the "generic" flags can always be added from offset 12
onward.
I think I get it.
Above, "no command" = "no vos subcommand", right?
And ultimately then for my changes I do not need to
alter the offset the COMMONPARMS get fed to, but it
would need to be altered if the decision was made to
allow more than 12 arguments to one vos "subcommand"?
On Wed, May 18, 2011 at 9:10 PM, Jeff Blaine<[email protected]> wrote:
Okay, I've made all -noexecute flags hidden, added
-dryrun where there was a -noexecute, and normalized
the help text for existing and new -dryrun args.
One thing I'm unsure of is how cmd_Seek() plays a
role in the modifications I've made. As a newb,
I figured I'd ping folks here for some feedback
before going further with git/gerrit.
src/cmd/cmd.c and src/cmd/cmd.h
cmd_Seek() checks if the position requested is
more than CMD_MAXPARMS and if not, sets the
"number of parms" (as->nParms) to the requested
position and returns 0. So the first thing I am
confused by is that nParms seems to be, by my
likely naive eye, completely mis-named, and should
be currParm or something.
In src/volser/vos.c for one (before and after
my edits, as I am not sure if I change 12), there
is:
#define COMMONPARMS cmd_Seek(ts, 12);\
cmd_AddParm(ts, "-cell", CMD_SINGLE, CMD_OPTIONAL, "cell name");\
cmd_AddParm(ts, "-noauth", CMD_FLAG, CMD_OPTIONAL, "don't authenticate");\
cmd_AddParm(ts, "-localauth",CMD_FLAG,CMD_OPTIONAL,"use server tickets");\
cmd_AddParm(ts, "-verbose", CMD_FLAG, CMD_OPTIONAL, "verbose");\
cmd_AddParm(ts, "-encrypt", CMD_FLAG, CMD_OPTIONAL, "encrypt commands");\
cmd_AddParm(ts, "-noresolve", CMD_FLAG, CMD_OPTIONAL, "don't resolve
addresses"); \
Can anyone shed some light on this stuff?
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
