I'm amazed about your puzzlement, since everybody else seem to get my
arguments, but as long as you play along I don't much care.
I will explain once more why it needs to be cut into two, even if you're
apparently willing to do it even without understanding:
When you reboot, you often cannot load the image.
This is _trivially_ true for panics or things like
- I don't understand why you do not want to accept this. Even if
your code doesn't even _handle_ panics, it's so obvious that
this is true that I don't understand why you want a limitation
in your particular current implementation to be a fundamental
flaw of the whole idea.
But it is _also_ true for any standard setup where you don't have
a special "init" that knows about loading the kernel, and where to
load it from.
- Do you want to rewrite every "init" setup out there, adding
some way to tell init where to load the kernel from?
Or do you want to just split the thing in two, so that you can
load the kernel _before_ you ask init to shut down, and just
happily use bog-standard tools that everybody is already
The two-part loader can clearly handle both cases. And if _you_ don't want
a two-part loader, you can do exactly what you do now by just doing two
As to vmalloc - I don't actually much care how the first and second parts
are implemented. I suggested a vmalloc()-like approach just because your
patch looks unnecessarily complicated to me. But while I am convinced that
the two-phase loading/exec is absolutely the way to do it, the actual
low-level implementation is just a detail.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/