Re: [RFC] Win32 port of the userspace tools using MinGW.
Hi, * Jamey Sharp [EMAIL PROTECTED] [2008-05-23 15:13]: I was hoping for more feedback than just code style though. :-) Of course. I'll give it a try first. I'm not very familar with Windows programming, though. I'm interested in kexec on Windows because it might be a nice way to start a Linux installation from Windows ... Bernhard ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] Win32 port of the userspace tools using MinGW.
* Jamey Sharp [EMAIL PROTECTED] [2008-05-23 15:13]: On Thu, May 22, 2008 at 6:34 AM, Bernhard Walle [EMAIL PROTECTED] wrote: * Jamey Sharp [EMAIL PROTECTED] [2008-05-15 22:48]: OK, I haven't quite gotten around to posting the Windows kernel driver source that goes with this. Do you plan to release the driver sources? Yes, and I've finally done so. The code I wrote is licensed under GPLv2 or later; some Linux kernel source is included verbatim or with modifications, and is licensed accordingly. http://source.thetovacompany.com/kexec-win/ I've only tried cross-compiling this code from Linux. In principle it should build with MinGW on Windows as well, if anyone cares. :-) That was my first approach, because I _thought_ it might be easier than cross-compiling. However, compiling kexec-tools on Windows did not work here because of several reasons. I fixed up everything, but I ended in a problem that I was not able to create a ET_REL binary of purgatory/purgatory.ro. The problem is that -Wl,--oformat didn't work (ld: cannot perform PE operations on non PE output file). Google advised me to use 'objcopy' -- however, that produced a ET_EXEC binary instead of ET_REL. The manual page of objcopy mentions However, copying a relocatable object file between any two formats may not work as expected. At that point, I gave up and gave the cross-compiler a try. That worked flawlessly. However, if somebody has an idea how to create a working ELF ET_REL file on Windows with Mingw, I can post the other fixups, so that we have a clean Windows port. I'm also able to _compile_ the driver (also on Windows), but I don't know how to _load_ the driver. Running kexec -l on Windows gave me an error message that loading fails, and it seems that the driver device file is just not there. Can you please advise me here? Bernhard ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] Win32 port of the userspace tools using MinGW.
On Fri, May 23, 2008 at 4:12 PM, Simon Horman [EMAIL PROTECTED] wrote: Firstly, thanks for your work in not only getting this port up and going, but methodically posted patches relating to it. You have made my job very easy :-) I tried. I'm happy to hear I succeeded. :-) The patch looks a little invasive, but I guess that is to be expected given the nature of what you re doing. I wonder if there will be other equally different ports (by which I mean its the first time the code has been made to work outside of some Linux environment) and thus whether it is worth abstracting some of these things somehow. Just a thought. Someone contacted me off-list about doing the same thing for MacOS X, which my employer wants as well. And I could imagine interest in similar work for various BSDs and others. So yes, making the code base more portable would make some people happy. There were a few cases where I added #ifdefs and Makefile conditionals that might affect other porters. Here are some suggestions for improving the kexec-tools' portability; I hope somebody else can pick them up... The largest affected pieces of code were for crashdump kernel loading. I have no idea how to hook the BSOD in Windows. :-) Other platforms will probably have the same problem. Allowing all crashdump support to be disabled at compile time would be an independent helpful patch. Some code is architecture-specific on Linux but may be platform-generic elsewhere. The get_memory_ranges function is an example: I think the copy in win32.c will work on all architectures that Windows supports, but /proc/iomem apparently is formatted a little differently on different Linux architectures. The physical_arch function I recently introduced should be another example, though its implementation is presently a bit kludged. I don't know how best to structure the code when some implementations should be in arch/ and some shouldn't. I think get_memory_ranges could stand to be completely refactored. First, the kexec-tools only require RANGE_RAM, AFAICT, so parsing more information out of /proc/iomem is wasted effort and extra maintenance cost. Then, most implementations are very similar. Looking over all the implementations and seeing how they can be unified would help. Finally, there are a handful of features that are not very portable and may not be so useful on other platforms anyway: - shutdown/reboot - current video mode detection - reusing kernel command line or initrd - bringing down network interfaces Making it easier to omit those features at compile-time would help with porting. I chose minimal-patch approaches for all of these, rather than clean fixes. I'm not opposed to the patch as it is. Awesome! I have very little time left to clean it up further, though like you I wish I were offering a less-invasive patch. Can you advise if there is any way to cross compile this code on a Linux (i686) box? Oh, I meant to mention that. I did all this development on a Debian x86-64 box; I cross-compiled everything for 32-bit targets as that's all I cared about. So my configure command is: ./configure --host=i586-mingw32msvc --target=i486-linux-gnu \ --build=x86_64-linux-gnu TARGET_CC=gcc -m32 (I overrode TARGET_CC because I don't have an i486-linux-gnu-gcc, just the 64-bit GCC with -m32.) The licence in include/byteswap.h. How does that effect the licencing of the rest of the code? Is it going to cause any distributions - I am thinking about Debian - to have a cow? I meant to mention that too. :-) Apparently the Cygwin license mentioned there can be found here: http://cygwin.com/license.html It's GPLv2, with a special exception for linking with code that meets the OSI's Open Source definition. If anyone is concerned, byteswap.h can be rewritten from scratch in a few minutes. :-) Last I checked, GCC on x86 generates the special x86 byte-swap instructions when fed the naive shift/or C implementation, so byteswap.h doesn't need to be anything fancy. Lastly, I'm a big fan of = 80 character wide lines. OK. I'll resubmit with 80-column line limits and the kernel brace style. Jamey ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[RFC] Win32 port of the userspace tools using MinGW.
OK, I haven't quite gotten around to posting the Windows kernel driver
source that goes with this. So I'm not asking that this patch be merged,
since nobody else can use it yet. :-) I'd love to get review, though:
Does this look like it's in a mergeable state? I'm happy with it, but do
I need to change anything to make it acceptable to you folks?
This patch requires basically all the other patches I've posted.
Makefile.in |1 +
include/byteswap.h| 39 +++
kexec/Makefile|6 +
kexec/arch/i386/Makefile |2 +
kexec/arch/i386/kexec-x86.c |2 +
kexec/arch/i386/x86-linux-setup.c |4 +
kexec/kexec-syscall.h |7 ++
kexec/kexec.c |4 +
kexec/kexec.h | 10 ++
kexec/win32.c | 214 +
10 files changed, 289 insertions(+), 0 deletions(-)
create mode 100644 include/byteswap.h
create mode 100644 kexec/win32.c
diff --git a/Makefile.in b/Makefile.in
index b51c3a1..bdd6ba7 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -24,6 +24,7 @@ ARCH = @ARCH@
OBJDIR = @OBJDIR@
target = @target@
host = @host@
+host_os= @host_os@
# Compiler for building kexec
CC = @CC@
diff --git a/include/byteswap.h b/include/byteswap.h
new file mode 100644
index 000..cd5a726
--- /dev/null
+++ b/include/byteswap.h
@@ -0,0 +1,39 @@
+/* byteswap.h
+
+Copyright 2005 Red Hat, Inc.
+
+This file is part of Cygwin.
+
+This software is a copyrighted work licensed under the terms of the
+Cygwin license. Please consult the file CYGWIN_LICENSE for
+details. */
+
+#ifndef _BYTESWAP_H
+#define _BYTESWAP_H
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+static __inline unsigned short
+bswap_16 (unsigned short __x)
+{
+ return (__x 8) | (__x 8);
+}
+
+static __inline unsigned int
+bswap_32 (unsigned int __x)
+{
+ return (bswap_16 (__x 0x) 16) | (bswap_16 (__x 16));
+}
+
+static __inline unsigned long long
+bswap_64 (unsigned long long __x)
+{
+ return (((unsigned long long) bswap_32 (__x 0xull)) 32) |
(bswap_32 (__x 32));
+}
+
+#ifdef __cplusplus
+}
+#endif
+#endif /* _BYTESWAP_H */
diff --git a/kexec/Makefile b/kexec/Makefile
index a80b940..fe05340 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
@@ -11,16 +11,22 @@ KEXEC_SRCS =
KEXEC_GENERATED_SRCS =
KEXEC_SRCS += kexec/kexec.c
+ifneq ($(host_os),mingw32msvc)
KEXEC_SRCS += kexec/ifdown.c
+endif
KEXEC_SRCS += kexec/kexec-elf.c
KEXEC_SRCS += kexec/kexec-elf-exec.c
KEXEC_SRCS += kexec/kexec-elf-core.c
KEXEC_SRCS += kexec/kexec-elf-rel.c
KEXEC_SRCS += kexec/kexec-elf-boot.c
KEXEC_SRCS += kexec/kexec-iomem.c
+ifneq ($(host_os),mingw32msvc)
KEXEC_SRCS += kexec/crashdump.c
KEXEC_SRCS += kexec/crashdump-xen.c
KEXEC_SRCS += kexec/phys_arch.c
+else
+KEXEC_SRCS += kexec/win32.c
+endif
KEXEC_GENERATED_SRCS += $(PURGATORY_HEX_C)
diff --git a/kexec/arch/i386/Makefile b/kexec/arch/i386/Makefile
index f2d9636..f9dbb7b 100644
--- a/kexec/arch/i386/Makefile
+++ b/kexec/arch/i386/Makefile
@@ -9,7 +9,9 @@ i386_KEXEC_SRCS += kexec/arch/i386/kexec-multiboot-x86.c
i386_KEXEC_SRCS += kexec/arch/i386/kexec-beoboot-x86.c
i386_KEXEC_SRCS += kexec/arch/i386/kexec-nbi.c
i386_KEXEC_SRCS += kexec/arch/i386/x86-linux-setup.c
+ifneq ($(host_os),mingw32msvc)
i386_KEXEC_SRCS += kexec/arch/i386/crashdump-x86.c
+endif
dist += kexec/arch/i386/Makefile $(i386_KEXEC_SRCS)\
kexec/arch/i386/kexec-x86.h kexec/arch/i386/crashdump-x86.h \
diff --git a/kexec/arch/i386/kexec-x86.c b/kexec/arch/i386/kexec-x86.c
index 89ccb0b..f937856 100644
--- a/kexec/arch/i386/kexec-x86.c
+++ b/kexec/arch/i386/kexec-x86.c
@@ -32,6 +32,7 @@
#include crashdump-x86.h
#include arch/options.h
+#ifndef __MINGW32__
static struct memory_range memory_range[MAX_MEMORY_RANGES];
/* Return a sorted list of memory ranges. */
@@ -113,6 +114,7 @@ int get_memory_ranges(struct memory_range **range, int
*ranges,
*ranges = memory_ranges;
return 0;
}
+#endif /* !defined(__MINGW32__) */
struct file_type file_type[] = {
{ multiboot-x86, multiboot_x86_probe, multiboot_x86_load,
diff --git a/kexec/arch/i386/x86-linux-setup.c
b/kexec/arch/i386/x86-linux-setup.c
index 4b9a5e5..e750d82 100644
--- a/kexec/arch/i386/x86-linux-setup.c
+++ b/kexec/arch/i386/x86-linux-setup.c
@@ -23,8 +23,10 @@
#include sys/types.h
#include sys/stat.h
#include fcntl.h
+#ifndef __MINGW32__
#include sys/ioctl.h
#include linux/fb.h
+#endif
#include unistd.h
#include x86/x86-linux.h
#include ../../kexec.h
@@ -101,6 +103,7 @@ void setup_linux_bootloader_parameters(
int setup_linux_vesafb(struct x86_linux_param_header *real_mode)
{
+#ifndef __MINGW32__
struct fb_fix_screeninfo fix;
struct fb_var_screeninfo var;
int fd;
@@ -153,6 +156,7 @@ int setup_linux_vesafb(struct x86_linux_param_header
Re: [RFC] Win32 port of the userspace tools using MinGW.
On Thu, May 15, 2008 at 10:48:13PM -0700, Jamey Sharp wrote:
OK, I haven't quite gotten around to posting the Windows kernel driver
source that goes with this. So I'm not asking that this patch be merged,
since nobody else can use it yet. :-) I'd love to get review, though:
Does this look like it's in a mergeable state? I'm happy with it, but do
I need to change anything to make it acceptable to you folks?
This patch requires basically all the other patches I've posted.
Hi Jamey,
Firstly, thanks for your work in not only getting this port up and going,
but methodically posted patches relating to it. You have made my job
very easy :-)
The patch looks a little invasive, but I guess that is to be expected
given the nature of what you re doing. I wonder if there will be other
equally different ports (by which I mean its the first time the code has
been made to work outside of some Linux environment) and thus whether it
is worth abstracting some of these things somehow. Just a thought. I'm
not opposed to the patch as it is.
Can you advise if there is any way to cross compile this code on a Linux
(i686) box? Its not critical, I'm more curious than anything else. But
if it is possible, it would at least allow me to check that the code
still compiles as other changes get merged in over time.
The licence in include/byteswap.h. How does that effect the licencing
of the rest of the code? Is it going to cause any distributions - I am
thinking about Debian - to have a cow?
Lastly, I'm a big fan of = 80 character wide lines.
--
Horms
Makefile.in |1 +
include/byteswap.h| 39 +++
kexec/Makefile|6 +
kexec/arch/i386/Makefile |2 +
kexec/arch/i386/kexec-x86.c |2 +
kexec/arch/i386/x86-linux-setup.c |4 +
kexec/kexec-syscall.h |7 ++
kexec/kexec.c |4 +
kexec/kexec.h | 10 ++
kexec/win32.c | 214
+
10 files changed, 289 insertions(+), 0 deletions(-)
create mode 100644 include/byteswap.h
create mode 100644 kexec/win32.c
diff --git a/Makefile.in b/Makefile.in
index b51c3a1..bdd6ba7 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -24,6 +24,7 @@ ARCH= @ARCH@
OBJDIR = @OBJDIR@
target = @target@
host = @host@
+host_os = @host_os@
# Compiler for building kexec
CC = @CC@
diff --git a/include/byteswap.h b/include/byteswap.h
new file mode 100644
index 000..cd5a726
--- /dev/null
+++ b/include/byteswap.h
@@ -0,0 +1,39 @@
+/* byteswap.h
+
+Copyright 2005 Red Hat, Inc.
+
+This file is part of Cygwin.
+
+This software is a copyrighted work licensed under the terms of the
+Cygwin license. Please consult the file CYGWIN_LICENSE for
+details. */
+
+#ifndef _BYTESWAP_H
+#define _BYTESWAP_H
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+static __inline unsigned short
+bswap_16 (unsigned short __x)
+{
+ return (__x 8) | (__x 8);
+}
+
+static __inline unsigned int
+bswap_32 (unsigned int __x)
+{
+ return (bswap_16 (__x 0x) 16) | (bswap_16 (__x 16));
+}
+
+static __inline unsigned long long
+bswap_64 (unsigned long long __x)
+{
+ return (((unsigned long long) bswap_32 (__x 0xull)) 32) |
(bswap_32 (__x 32));
+}
+
+#ifdef __cplusplus
+}
+#endif
+#endif /* _BYTESWAP_H */
diff --git a/kexec/Makefile b/kexec/Makefile
index a80b940..fe05340 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
@@ -11,16 +11,22 @@ KEXEC_SRCS =
KEXEC_GENERATED_SRCS =
KEXEC_SRCS += kexec/kexec.c
+ifneq ($(host_os),mingw32msvc)
KEXEC_SRCS += kexec/ifdown.c
+endif
KEXEC_SRCS += kexec/kexec-elf.c
KEXEC_SRCS += kexec/kexec-elf-exec.c
KEXEC_SRCS += kexec/kexec-elf-core.c
KEXEC_SRCS += kexec/kexec-elf-rel.c
KEXEC_SRCS += kexec/kexec-elf-boot.c
KEXEC_SRCS += kexec/kexec-iomem.c
+ifneq ($(host_os),mingw32msvc)
KEXEC_SRCS += kexec/crashdump.c
KEXEC_SRCS += kexec/crashdump-xen.c
KEXEC_SRCS += kexec/phys_arch.c
+else
+KEXEC_SRCS += kexec/win32.c
+endif
KEXEC_GENERATED_SRCS += $(PURGATORY_HEX_C)
diff --git a/kexec/arch/i386/Makefile b/kexec/arch/i386/Makefile
index f2d9636..f9dbb7b 100644
--- a/kexec/arch/i386/Makefile
+++ b/kexec/arch/i386/Makefile
@@ -9,7 +9,9 @@ i386_KEXEC_SRCS += kexec/arch/i386/kexec-multiboot-x86.c
i386_KEXEC_SRCS += kexec/arch/i386/kexec-beoboot-x86.c
i386_KEXEC_SRCS += kexec/arch/i386/kexec-nbi.c
i386_KEXEC_SRCS += kexec/arch/i386/x86-linux-setup.c
+ifneq ($(host_os),mingw32msvc)
i386_KEXEC_SRCS += kexec/arch/i386/crashdump-x86.c
+endif
dist += kexec/arch/i386/Makefile $(i386_KEXEC_SRCS) \
kexec/arch/i386/kexec-x86.h kexec/arch/i386/crashdump-x86.h \
diff --git a/kexec/arch/i386/kexec-x86.c b/kexec/arch/i386/kexec-x86.c
index 89ccb0b..f937856 100644
---
