On Tue, Oct 19, 2010 at 7:27 AM, Phillip Moore <[email protected]> wrote: > > Would you accept a patch that introduces two new fs commands: > > fs getprecache > fs setprecache > and that "hides" the precache command? IOW, precache will work, but it will > not show up in fs help output. This introduces a new pair of get/set > commands, and would give admins the ability to query the value, and > therefore manage it. > Alternately, fs precache can be modified to display the value when no > arguments are provided, instead of generate a syntax error like it does > right now.
Either is fine. A hidden deprecated command might be better in 1.6 (documented as existing but deprecated) and the master can simply not have the command at all so that when 1.next hits, ti's already gone. > There's a lack of consistency in the fs commands, but my personal preference > is for get/set commands when we add new features, as opposed to a single > command for both setting and querying something. > On Mon, Oct 18, 2010 at 1:50 PM, Derrick Brashear <[email protected]> wrote: >> >> On Mon, Oct 18, 2010 at 1:45 PM, Phillip Moore >> <[email protected]> wrote: >> > Another fs command I can't find any documentation for: fs precache >> > In this case, it appears that there's no way to query the value. This >> > seems like bad interface design to me. If there's a mechanism for >> > setting >> > an important value that changes the behavior of the client, there has to >> > be >> > a mechanism for querying that value. Otherwise, you can't manage it. >> > Write-only, read-never parameters are very bad. >> > Looking at the code in src/venus/fs.c, it looks to me like this *should* >> > have been implemented as a pair of CLI commands: setprecache and >> > getprecache, and in fact, that should be straight forward, and fully >> > backwards compatible. >> >> Probably. And I take blame for that. >> >> > Is this another bleeding edge feature that the authors thought wasn't >> > important enough to write a man page for? >> >> No. >> >> >> >> -- >> Derrick > > -- Derrick _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
