On 2013/8/15 1:34, Dhaval Giani wrote: > On Wed, Aug 14, 2013 at 3:18 AM, Libo Chen <clbchenlibo.c...@huawei.com> > wrote: >> On 2013/8/14 11:24, Dhaval Giani wrote: >>> Hi! >>> >>> On Tue, Aug 13, 2013 at 10:39 PM, Libo Chen <clbchenlibo.c...@huawei.com> >>> wrote: >>>> On 2013/8/14 4:37, Dhaval Giani wrote: >>>>> On Tue, Aug 6, 2013 at 3:15 AM, Libo Chen <clbchenlibo.c...@huawei.com> >>>>> wrote: >>>>>> >>>>>> we should check invalite parameter, and then print a warning >>>>>> >>>>>> Signed-off-by: Libo Chen <clbchenlibo.c...@huawei.com> >>>>> >>>>> I'm not sure this extra warning is needed. In most unix software, if >>>>> you use an invalid argument, the help is printed, which is exactly >>>>> what happens here. >>>>> >>>>> Thanks! >>>>> Dhaval >>>>> >>>> >>>> Hi Dhaval, >>>> >>>> Thanks for your attention! Let me explain the scene. >>>> >>>> before patch: >>>> run command "cgconfigparser x". 'x' is invalid argument, but no >>>> tips and no help info! >>>> >>>> >>>> But I think tip is needed! >>>> >>>> after patch: >>>> "cgconfigparser: wrong arguments (x)" will be threw out! >>> >>> grrr. So my brain is not working right now. However some things to be >>> kept in mind, >>> >>> usage() exits. So if you want to print that message, you probably want >>> to be printing before usage (for one). >> >> Now, run command "cgconfigparser x", there is no info spew out include >> usage(). >> so I add "cgconfigparser: wrong arguments (x)" tip. >> >>> >>> Next, can you change the message to match something similar to what an >>> invalid option to "ls" would spew out. >> >> I refer the command cgcreate, but maybe we can use usage() instead only? >> > > $ ls -y > ls: illegal option -- y > usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...] > > I would like something like this.
Hi Dhaval, yes, it is the bash style. But this patch follows libcg style, this is important too? >> >>> Finally, a quick read through that code, and I can see quite a few >>> things that need to be changed/corrected. We are freeing up >>> default_cgroup even it has not be allocated. That needs to be >>> corrected. >>> >> >> Don`t worry. cgroup_free() is safe even if default_group is NULL. >> > > While true, there is no need to make the call if not required. So yes, > it is a cleanup I would like :-). > This problem already exists, you can make a patch to fix it. :) > Thanks! > Dhaval > > ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
