> On Tue, 2002-11-05 at 18:00, Werner Almesberger wrote:
> > Yes, I've just checked with Eric, and he hasn't received any
> > indication from Linus so far. I posted a reminder to linux-kernel.
> > I'd really hate to see kexec miss 2.6.
>
> Let me ask the same dumb question - what does kexec need that a dumper
> doesn't. In other words given reboot/trap hooks can kexec happily live
> as a standalone module ?
In replying to another post by Al Viro I managed to think this through.
kexec needs:
- An allocated slot in some namespace.
- The ability to request the kernel devices shut themselves down.
- Buffers that are safe to use.
- The ability to transition the cpu into a state that is suitable
for jumping to another kernel.
- Awareness of it's existence.
Most of this code is intimate with how the kernel currently behaves
and needs at least minor adjustments for things like living in PAE
mode.
The safe buffers a kernel can probably avoid.
I cannot see the core functionality of kexec every living happily as a
standalone module. The kexec code accomplishes nothing. If there is
something useful it does it can probably be moved elsewhere and the
line count reduced. The entire code base is basically obsessed with
getting safe temporary buffers for the new kernel to live in, and
given improvements to how the kernel allocates memory that are
theoretically possible with rmap I could remove that code as well.
The only thing that keeps kexec at all maintainable outside the kernel
is that big fundamental changes do not happen often. But the kernel
must be tracked, closely. I don't see that as a recipe for a
standalone module. I can barely even see making the code a module, or
what the point would be.
The reason kmonte fails in so many cases where kexec succeeds is
precisely because kmonte is a module.
If we include machine_kexec or something very similar to but more
generalized to the list of exported functions, perhaps kexec could
just have the buffer allocation code and live happily outside of the
kernel. But as it is, if we want to factor kexec into pieces so one
piece can live happily as a standalone module it will take some
serious design work, and a total rethink of the implementation. And
we will still have to add code to the kernel.
Eric
-
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/