Anomalous Force wrote:
> you miss my point. im not saying to model it after tcp/ip. that
> was just a reference to a method of data exchange wherein the
> data has metadata to describe it.
I understood that. What I was saying is that metadata in a TCP
connection is usually not sufficient for restoring the endpoint
state.
> it makes full sense in an enterprise with 3000+ users that operates
> 24/7/365. no scheduled down-time for kernel upgrades.
I don't disagree with the usefulness of such functionality, but
I disagree with the level at which you suggest to implement this.
The approach of trying to migrate low-level kernel state has the
following problems/disadvantages:
- complexity
- does not allow recovery from corrupt kernel state, as Pavel has
suggested
- does not support recovery from corrupt hardware state
- does not support substitution of infrastructure (e.g. what if
I want to fail over to a different machine, maybe quickly
replace some non-hotpluggable hardware (*), or even swap that
old disk with a new one that has completely different
characteristics ?)
So, compared to an approach that implements this at the kernel to
user space API level, you get a lot of extra complexity, but miss
several very desirable features.
(*) While the "big iron" in your data center may have hot-swappable
CPUs and everything, it would be nice if such things could also
be done with commodity hardware that doesn't provide such
luxury.
> this is not true. if the system were an integral part of the overall
> design, then programming would include it apriori.
Making something part of the design alone doesn't guarantee that
this is a good approach, nor that it will actually work :-)
> there is a fine distinction between kernel migration, and hot-swap.
> in a hot-swap setup, there will be signals pending from devices
[...]
Err, yes, but what does your "hot-swap" do that kernel migration
doesn't ?
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ - 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/
This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:15 EST