KAMEZAWA Hiroyuki wrote: > On Tue, 25 Sep 2007 16:19:18 +0530 > Balbir Singh <[EMAIL PROTECTED]> wrote: > >> Hi, Kamezawa-San, >> > Hi, > >> Your changes make sense, but not CLUI (Command Line Usage) sense. >> 1. The problem is that when we mix strings with numbers, tools that >> parse/use get confused and complicated > yes, maybe. > >> 2. ULONGLONG_MAX is a real limit, there is no such thing as unlimited. >> If the user does ever go beyond ULONGLONG_MAX, we will limit him :-) >> > Oh. res_counter.c uses LONGLONG_MAX as default value. > need fix ? or intended ?
Pavel do you remember why LONG was chosen instead of ULONG? > And okay there is no "unlimited" state. > >> Having said that, I do wish to have a more intuitive interface for >> users. May be a perl/python script to hide away the numbers game >> from the users. What do you think? >> > I agree with you that perl/python script can hide details. but they need > knowledge > about the maximum value, which is given as default value. > > In short, what I want is some value like RLIM_INFINITY in ulimit. > I like the idea of RLIM_INFINITY and how ulimit as a tool shows a value. I guess we need something like RES_COUNTER_LIMIT_MAX and the user tool can show the limit as maximum. We could also define a special number, RES_COUNTER_LIMIT_INFINITY, such that containers will not enforce limits when the limit is set to this value. > > Because it seems that res_counter.c will be used for other resouce control > purpose, > I thought some generic way (value) to know/specify "the maximum value" is > helpful for > all resource controller interface. > > If there is an concensus that treaing ULONGLONG_MAX as default, it's ok. > When I worked on the first version of res_counters, I used 0 to indicate unlimited. When Pavel posted his version, I think derived from beancounters, we did not want to have unlimited containers, so he used the maximum value > Thanks, > -Kame > Thanks for looking into this, -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel