On Thu, Jan 07, 2010 at 03:14:32AM -0500, Ben Blum wrote: > On Thu, Jan 07, 2010 at 02:42:19PM +0800, Li Zefan wrote: > > KAMEZAWA Hiroyuki wrote: > > > On Wed, 6 Jan 2010 20:26:06 -0500 > > > Ben Blum <bblum@xxxxxxxxxxxxxx> wrote: > > > > > >> On Wed, Jan 06, 2010 at 04:04:14PM -0800, Andrew Morton wrote: > > >>> On Thu, 31 Dec 2009 00:10:50 -0500 > > >>> Ben Blum <bblum@xxxxxxxxxxxxxx> wrote: > > >>> > > >>>> This patch series implements support for building, loading, and > > >>>> unloading subsystems as modules, both within and outside the kernel > > >>>> source tree. It provides an interface cgroup_load_subsys() and > > >>>> cgroup_unload_subsys() which modular subsystems can use to register and > > >>>> depart during runtime. The net_cls classifier subsystem serves as the > > >>>> example for a subsystem which can be converted into a module using these > > >>>> changes. > > >>> What is the value in this? What are the usage scenarios? Why does the > > >>> benefit of this change exceed the cost/risk/etc of merging it? > > >> As discussed in the first posting of these patches, this provides the > > >> ability for arbitrary subsystems to be used with cgroups.. cls_cgroup > > >> would have already been a module except for a lack of support from > > >> cgroups, and the change also allows other module-loadable classifiers > > >> to add subsystems of their own. > > > > > > Hmm, do you have your own module in plan ? > > > > > > > Maybe the new blkio_cgroup can also be made module-able. > > certainly looks promising. one thing I note while looking over it is > that it wants .use_id = 1, and the load_subsys interface neglects to > make a call to init_idr. adding calls to cgroup_init_idr has a few > possible complications... what use does blkio have for use_id? oh, oops, while tracing the calls that init_idr does i ended up looking at the wrong functions and made it out to be harder than it was (in several places, even). still it would need to be included in load_subsys and the single error case handled appropriately. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
