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! Thanks, Yuan |