[Qemu-devel] OpenBSD build fixes

[Qemu-devel] OpenBSD build fixes

[Laurence Tratt]

This mail contains two simple patches - after the .sig - which make most of
qemu build under OpenBSD. The first is a patch to signrom.sh to work around
the fact that OpenBSD's od does not have a -A option; this change should be
compatible with other OS's and not lead to any detectable change in
functionality. The other patch is to configure, which makes INSTALL_DIR call
both -d and -p; -p is invalid with -d under OpenBSD (and, I suspect, some
other Unix's too).

It would be good if we could get these patches into the mainline qemu. From
here, there are a couple of more obviously OpenBSD-only patches that aren't
suitable for the main qemu tree, and will need to be maintained seperately.
But with all of them in place, I have a functioning qemu and, for the first
time under OpenBSD/amd64, a qemu that doesn't crash when it uses the network
- which is a big improvement!

Thanks to Juergen Lock and blauwirbel@gmail.com for help in getting qemu
working under OpenBSD.


Laurie
-- 
http://tratt.net/laurie/ -- Personal
http://fetegeo.org/      -- Free text geocoding
http://convergepl.org/   -- The Converge programming language
http://www.model-transformation.org/ICMT2010/ -- ICMT 2010

diff --git a/pc-bios/optionrom/signrom.sh b/pc-bios/optionrom/signrom.sh
index 975b27d..0eb091d 100755
--- a/pc-bios/optionrom/signrom.sh
+++ b/pc-bios/optionrom/signrom.sh
@@ -26,12 +26,16 @@ test "$1" -a "$2" || exit 1
 sum=0
 
 # find out the file size
-x=`dd if="$1" bs=1 count=1 skip=2 2>/dev/null | od -t u1 -A n`
+tmp=`mktemp`
+dd if="$1" bs=1 count=1 skip=2 2>/dev/null > $tmp
+x=`od -v -t u1 $tmp | head -n 1 | cut -d " " -f 2- | sed "s/ //g" | sed "s/^0*//g"`
+rm $tmp
 #size=`expr $x \* 512 - 1`
 size=$(( $x * 512 - 1 ))
 
 # now get the checksum
-nums=`od -A n -t u1 -v "$1"`
+num_lines=`od -v -t u1 "$1" | wc -l`
+nums=`od -v -t u1 "$1" | head -n $(( num_lines - 1 ))  | cut -d " " -f 2-`
 for i in ${nums}; do
     # add each byte's value to sum
     sum=`expr $sum + $i`
diff --git a/configure b/configure
index 69a5502..64a920a 100755
--- a/configure
+++ b/configure
@@ -2042,7 +2042,7 @@ echo "datadir=\${prefix}$datasuffix" >> $config_host_mak
 echo "docdir=\${prefix}$docsuffix" >> $config_host_mak
 echo "MAKE=$make" >> $config_host_mak
 echo "INSTALL=$install" >> $config_host_mak
-echo "INSTALL_DIR=$install -d -m0755 -p" >> $config_host_mak
+echo "INSTALL_DIR=$install -d -m0755" >> $config_host_mak
 echo "INSTALL_DATA=$install -m0644 -p" >> $config_host_mak
 echo "INSTALL_PROG=$install -m0755 -p" >> $config_host_mak
 echo "CC=$cc" >> $config_host_mak

Re: [Qemu-devel] OpenBSD build fixes

[Stuart Brady]

On Mon, Oct 05, 2009 at 09:16:28PM +0100, Laurence Tratt wrote:
> It would be good if we could get these patches into the mainline qemu. From
> here, there are a couple of more obviously OpenBSD-only patches that aren't
> suitable for the main qemu tree, and will need to be maintained seperately.

Aren't suitable for the main QEMU tree?  Why?

Is it somehow a *good* thing for upstream releases not to work OOTB under
the BSDs?  I really don't understand this...

(Or is the name "ports" being taken too literally?)

Cheers,
-- 
Stuart Brady

Re: [Qemu-devel] OpenBSD build fixes

[Laurence Tratt]

On Mon, Oct 05, 2009 at 09:57:50PM +0100, Stuart Brady wrote:

>> It would be good if we could get these patches into the mainline qemu.
>> From here, there are a couple of more obviously OpenBSD-only patches that
>> aren't suitable for the main qemu tree, and will need to be maintained
>> seperately.
> Aren't suitable for the main QEMU tree?  Why?
>
> Is it somehow a *good* thing for upstream releases not to work OOTB under
> the BSDs?  I really don't understand this...
>
> (Or is the name "ports" being taken too literally?)

In an ideal world, I would love qemu to work out of the box on OpenBSD. Both
the things I'm referring to relate to things that appear simply to be
missing from OpenBSD - for example ONLY_IF_RO prevents x86_64.ld from
compiling, and has to be removed. While I'd be happy to see those removed
from the tree, I assume they have semantic meaning for other platforms, and
that's something we have to live without. As this implies, this stuff is a
little outside my normal experience, but given that no-one else more
qualified has ported a recent version of qemu to OpenBSD [/amd64 in
particular], I guess it'll have to do!


Laurie
-- 
http://tratt.net/laurie/ -- Personal
http://fetegeo.org/      -- Free text geocoding
http://convergepl.org/   -- The Converge programming language
http://www.model-transformation.org/ICMT2010/ -- ICMT 2010

Re: [Qemu-devel] OpenBSD build fixes

[Stuart Brady]

On Mon, Oct 05, 2009 at 10:23:35PM +0100, Laurence Tratt wrote:

> In an ideal world, I would love qemu to work out of the box on OpenBSD. Both
> the things I'm referring to relate to things that appear simply to be
> missing from OpenBSD - for example ONLY_IF_RO prevents x86_64.ld from
> compiling, and has to be removed. While I'd be happy to see those removed
> from the tree, I assume they have semantic meaning for other platforms, and
> that's something we have to live without. As this implies, this stuff is a
> little outside my normal experience, but given that no-one else more
> qualified has ported a recent version of qemu to OpenBSD [/amd64 in
> particular], I guess it'll have to do!

I *think* it should be safe to drop the lines using ONLY_IF_RO, provided
that you also make the ONLY_IF_RW lines be unconditional.

The proper fix might be to pass the script through a preprocessor
(perhaps the C preprocessor, with a set of #ifdefs) on affected hosts.

Note that ia64, m68k and s390 also mark .eh_frame and .gcc_except_table
with KEEP { ... }, but place them in the data segment (i.e. without
using ONLY_IF_RO and ONLY_IF_RW).  I expect that you're only really
concerned with x86_64 for the time being, but note that hppa, mips, ppc
and ppc64 also use ONLY_IF_RO and ONLY_IF_RW.

I'd certainly argue that it's best to post any OpenBSD-specific patches
to the list with [RFC] in the subject line, so that anyone who might
know a better fix for a specific issue can offer their suggestions.
It's sometimes the case that a fix is also relevant to one of the other
Un*xes or Windows, so I think it's well worth keeping the list informed
of any issues that you find.

Also, I feel that it's worth having the current code in Git compile and
run under OpenBSD -- I can't see any reason to treat OpenBSD as a second
class citizen, nor any other significant OS.

Cheers,
-- 
Stuart Brady