Re: holy grail

[Werner Almesberger <wa@almesberger.net>]

Anomalous Force wrote:
> what if the new kernel asked the old kernel to hand over the data in
> a form that was understood universally beginning at some kernel
> version X (earliest supported kernel in other words).

Yes, and that information would ideally just be what is visible
from user space. This gives you a well-defined abstraction, and
limits the dependency on kernel internals.

> im thinking of something along the lines of a data packet (tcp/ip
> comes to mind) that contains data about its data.

I guess you never looked at how much state TCP really carries
around :-) For a rough idea, you may want to have a look at
tcpcp (TCP Connection Passing), which does pretty much what you'd
have to do for this kind of checkpointing:
http://www.almesberger.net/tcpcp/

Now, there are a few things to consider:

 - tcpcp ignores several rare conditions, such as urgent mode
 - tcpcp doesn't even try (yet) to preserve congestion control
   information, which is about twice the current amount of
   information again
 - even with all those constraints, there are almost certainly
   some things I've overlooked
 - that's only TCP, i.e. one of several networking protocols. And
   networking is just one of many subsystems. And what tcpcp does
   is not even transparent to applications.
 - while TCP is certainly not trivial, there is a reasonably well
   defined abstraction of its state, which simplifies this kind of
   checkpointing

And remember, this is still only about what can be seen from user
space. No attempt is made to transplant timers, memory allocations,
cloned skbs, etc.

> yes, it would be extremely difficult. but, as with all fields of
> endevour, a holy grail is only such because it is. the question
> remains, is this do-able? perhaps not now, or in two years, but
> what about five? say, kernel 3.x.x or even 4.x.x?

For full direct kernel-to-kernel migration, I'm fairly confident
the answer is "never", simply because it doesn't make sense, and
because it would be completely unmaintainable (1,2). (I expect to
see some information passing for things like IDE or SCSI bus scan
results, though.)

(1) Okay, I'll reverse my prognosis when we've had, say, ten new
    kernels in a row, without any obvious major bugs or build
    problems :-)
(2) If you dig out IFS, you'll see a nice example of why you
    don't want to create too many dependencies on kernel
    internals :-) http://www.almesberger.net/epfl/ifs.html

For userspace-to-userspace, we can probably do some things already
today (e.g. "classical" batch jobs), and I guess we might be able
to migrate reasonably complete systems in maybe one or two years,
if somebody starts working on the corner cases that aren't of much
interest for process migration (e.g. video, audio, etc.).

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/