> B2 corresponds to my patch where in which instead of unmounting all > subsystem in error path, it tries to unmount first and retries mounting all > the subsystem. In the usecase given, instead of unmounting memory > explicitly, and then retrying, we can see that it silently succeeds (may be > a warning was more meaningful). >
Which is absolutely wrong. It should *not* silently destroy other subsystems which have been (probably) setup in some fashion. We do not break other users of cgroups. So no, this patch/approach will not be accepted. > B3 is what is seen now in mainline, it is seem to be logically sound, in the > sense it does not touch the previously mounted subsystem, it is irritating > for the user who supposedly has mounted one subsystem and > wants to see 5 subsystem to be mounted, with the continuous complaints. > Every time, when even a single subsystem is mounted, he would have to do > manually unmount/cgclear. > Its pretty easy to script it, and also its quite easy to setup different config files and load those. I don't buy this argument. Having said that we should improve the error message telling which subsystem is already mounted and caused the failure. > In my opinion this is not the only best option we can have. > 1.How about continuing with the mounting of other subsystems even if we > notice, one/more of subsystem is mounted ? (B4) And how do you then tell the user that we have not successfully setup the cgroups as requested by him. What if, let's say, cpu is mounted at one place and the config file wants to mount all the subsystems together? > 2.How about having a tunable, leaving the option to the user the way he > wishes the behaviour to be either B2/B3/B4? IMHO the only sane behaviour is B3 with an improved error message. Dhaval ------------------------------------------------------------------------------ FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
