Actually, instead of a hidden command, how about making precache an alias to setprecache? That seems simpler to implement.
However, it's unclear to me how to make a change in 1.6. Do I need to patch a specific branch? On Tue, Oct 19, 2010 at 8:52 AM, Derrick Brashear <[email protected]> wrote: > 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 >
