From sha0.miller at gmail.com Wed Oct 3 16:52:10 2012 From: sha0.miller at gmail.com (Shao Miller) Date: Wed, 3 Oct 2012 12:52:10 -0400 Subject: [kexec] Native-Mode Stuff In-Reply-To: <506c66b4.8697320a.1ba7.38d6@mx.google.com> Message-ID: <506c6d3b.05d4320a.49cf.4803@mx.google.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha0.miller at gmail.com Wed Oct 3 17:21:00 2012 From: sha0.miller at gmail.com (Shao Miller) Date: Wed, 3 Oct 2012 13:21:00 -0400 Subject: [kexec] Building with Fedora 17 Message-ID: <506c73fe.07ca320a.5e73.7e32@mx.google.com> Just a little note for Fedora 17 users having the mingw32-headers-2.0.999-0.7.trunk.20120601.fc17.noarch package installed: Before building, you might need to: export CPATH=/usr/i686-w64-mingw32/sys-root/mingw/include/ddk As otherwise there might be an error: /usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h:38:17: fatal error: wdm.h: No such file or directory - Shao Miller -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 663 bytes Desc: not available URL: From stump at jstump.com Wed Oct 3 17:43:20 2012 From: stump at jstump.com (John Stumpo) Date: Wed, 03 Oct 2012 13:43:20 -0400 Subject: [kexec] Native-Mode Stuff In-Reply-To: <506c6d3b.05d4320a.49cf.4803@mx.google.com> References: <506c6d3b.05d4320a.49cf.4803@mx.google.com> Message-ID: <506C7938.4020902@jstump.com> 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 From sha0.miller at gmail.com Wed Oct 3 17:59:38 2012 From: sha0.miller at gmail.com (Shao Miller) Date: Wed, 03 Oct 2012 13:59:38 -0400 Subject: [kexec] Native-Mode Stuff In-Reply-To: <506C7938.4020902@jstump.com> References: <506c6d3b.05d4320a.49cf.4803@mx.google.com> <506C7938.4020902@jstump.com> Message-ID: <506C7D0A.3080309@gmail.com> On 10/3/2012 13:43, John Stumpo wrote: > > 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. Good point. > 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.) Please do. :) - Shao Miller