![]() | |||||||||||||
Messages in this thread |
Paul Jackson wrote: > Pavel wrote:>>>> 3. Configfs may be easily implemented later as an additional >>>> interface. I propose the following solution: >>>> ...>> Resource controller has nothing common with confgifs. >> That's the same as if we make netfilter depend on procfs.> > Well ... if you used configfs as an interface to resource > controllers, as you said was easily done, then they would > have something to do with each other, right ;)? Right. We'll create a dependency that is not needed. > Choose the right data structure for the job, and then reuse > what fits for that choice.> > Neither avoid nor encouraging code reuse is the key question. > > What's the best fit, long term, for the style of kernel-user > API, for this use? That's the key question. I agree, but you've cut some importaint questions away, so I ask them again: > What if if user creates a controller (configfs directory) > and doesn't remove it at all. Should controller stay in > memory even if nobody uses it? This is importaint to solve now - wether we want or not to keep "empty" beancounters in memory. If we do not then configfs usage is not acceptible. > The same can be said about system calls interface, isn't it? I haven't seen any objections against system calls yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-10-30 16:33 [from the cache] ©2003-2008 | |||||||||||||