On Tue, 2006-04-18 at 10:28 +0900, MAEDA Naoaki wrote:
> Matt Helsley wrote:
> > On Mon, 2006-04-17 at 11:47 -0700, Chandra Seetharaman wrote:
> >> The reason i made it a bool is we merged ckrm_iface to rcfs, and
> >> ckrm_iface was using put_task_struct, which is not an exported symbol.
> >>
> >> May be we can add a new function to core, that takes a pid, instead of a
> >> task data struture, to set the class that does the get/put_task_struct.
> >>
> >> Comments anybody ?
> >
> > I would rather see the options merged than add a function that takes a
> > pid. I don't think merging RCFS with the CKRM option adds much (if any)
> > overhead in the case that CKRM is unused, and keeping the interface as a
> > separate option doesn't seem necessary. Also, RCFS will only appear when
> > configfs gets mounted anyway.
>
> That makes sense. But a flaw of this approach is it also forces configfs
> statically linked to a vmlinux. Do you think it is acceptable?
>
> Thanks,
> MAEDA Naoaki
Ah. Right -- so it would still make sense to be able to build configfs
and rcfs as a module. However, that said I still think there should only
be one CONFIG option -- CONFIG_CKRM. However, make it a tristate and, if
it's =m build rcfs as a module. If it's =y then staticly-link rcfs and
configfs into the kernel. The point being that in either case rcfs
should be built.
Cheers,
-Matt Helsley
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
