At Wed, 19 Oct 2011 16:01:42 +0800, Liu Yuan wrote: > > On 10/19/2011 03:43 PM, MORITA Kazutaka wrote: > > > At Wed, 19 Oct 2011 14:35:05 +0800, > > Liu Yuan wrote: > >> > >> On 10/19/2011 02:25 PM, MORITA Kazutaka wrote: > >> > >>> Signed-off-by: MORITA Kazutaka <morita.kazutaka at lab.ntt.co.jp> > >>> --- > >>> Hi Yuan, > >>> > >>> Isn't it better to add a nohalt field instead of a generic name > >>> "flags"? This would be the most intuitive way. The size of config > >>> file wouldn't become a problem, so we don't need to save bits, I > >>> think. > >>> > >>> How do you think? > >>> > >> > >> > >> Hi Kazum, > >> > >> I think we'd better live with flags. with set/get_cluster_falgs(). Then > >> we can add more options (for e.g. noqlimit, no rquest queue limit later > > > > I guess these options are not cluster-wide ones. The size of the > > limit depends on each machine spec. How about make them the sheep > > command line options? > > > > > Hmm, the noqlimit is just my example, thought it is lame. For rquest > queue limit specifically, I agree with you. > > >> for the cluster that doesn't need it at all. etc.), which will use this > >> interface to store it in the local storage. > >> > >> If not, we'll have to write functions to store those options locally > >> every time we add a new option. > > > > But we need to define set/get functions in either case when we add a > > non-boolean option to sheepdog_config. In addition, I'm not sure we > > really have so many cluster-wide options. > > > Ah, then 16 options would be good enough for cluster wide option. So > nohalt is the first one. And I think, there are more cases to come, that > just need one bit. > > If non-boolean option really makes its debut, we can then write some > generic functions to handle those case. > > > > > Anyway, we should read sheepdog_config only when starting Sheepdog, > > then we don't need to implement a get function for each field. > > > > > Then, this does support flags! Okay, agreed, let's use flags :) Thanks, Kazutaka |