[kexec] Native-Mode Stuff

John Stumpo stump at jstump.com
Wed Oct 3 17:43:20 UTC 2012


On 10/03/2012 12:52 PM, Shao Miller wrote:
> Hey again, John.
> 
> I was wondering: What would you think if:
> 
> ·                     I moved some stuff out of kexeccommon.dll and into
> a new ntkexec/ntkexec.dll, which would only depend on ntdll.dll
>
> ·                     Made a new ntclient/ntkexec.exe that only depends
> on the above-mentioned ntkexec.dll
>
> ?  The end goal being to have a native-mode version of the client so
> that WinKexec could be used without involving any of the Win32
> subsystem.  (Think a tiny Windows image for doing something Windowsey
> and then booting a Linux and passing some info along.)
>
> - Shao Miller

I like the idea of native-mode functions and a native-mode client, but I
think I'd rather have KexecCommon continue using win32 calls itself.
(I'd like there to be at least one part of the package that sticks to
officially documented APIs, which is the case for the existing client code.)

So a native-mode client would be highly welcomed, but I'd like to keep
KexecCommon the way it is for now.

I'd ultimately like to turn the userspace interface into a
Linux-compatible kexec_load() function (which would be in a libkexec of
some kind and just wrap a new ioctl) and try to make the Linux kexec
userspace tool work with it, allowing more types of images to be loaded
with further customization occurring in userspace. That doesn't seem
like it would be very friendly to native mode, so I'll probably find a
way to keep the current ioctls around if I do this. Whether I'll keep
the current clients and KexecCommon after doing so is an open question,
though.

(Maybe I should send out a separate message listing what I want to
implement that hasn't been so far.)

Cheers,
--stump


More information about the kexec mailing list