OpenVZ Forum - RDF feed
type: channel
items: Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch

Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch
type: item
description: On Thu, 18 Nov 2010 10:48:34 +0100 Tejun Heo <tj@kernel.org> wrote: > Hello, Pavel. > > On 11/18/2010 10:13 AM, Pavel Emelyanov wrote: > >>> By this do you mean the very idea of having CR support in the > >>> kernel? Or our design of it in the kernel? > >> > >> The former, I'm afraid. > > > > Can you elaborate on this please? > > I think I already did that several times in this thread but here's an > attempt at summary. Yet the arguments seem to be vague enough not to be convincing to the people working on the code. > * It adds a bunch of pseudo ABI when most of the same information is > available via already established ABI. Can you elaborate on this? What established ABI are you proposing we use here. Hopefully we can turn this into a more technical discussion. > * In a way which can only ever be used and tested by CR. If possible, So what if it can only be tested with CR as long as we can make CR work on a variety of environments? Scalability changes for _really_ large SMP boxes can only be reliably tested by people such equipment. We are not imposing any such restriction and this code can be tested on very wide range of setups. > kernel should provide generic mechanisms which can be used to > implement features in userland. One of the reasons why we'd like to > export small basic building blocks instead of full end-to-end > solutions from the kernel is that we don't know how things will > change in the future. In-kernel CR puts too much in the kernel in a > way too inflexible manner. > > * It essentially adds a separate complete set of entry/exit points for > a lot of things, which makes things more error prone and increases > maintenance overhead across the board. I partially agree with you here. There will be maintenance overhead every time you add code to the kernel that _may_ make changes in the future more complicated. This true for _any_ code that is added to the core kernel. Now in my experience such maintenance burden is most disruptive when the code bei…
creator: Jose R. Santos
date: 2010-11-18T20:13:27-00:00