qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] All the world's a VAX! - reloaded


From: Patrick M. Hausen
Subject: [Qemu-devel] All the world's a VAX! - reloaded
Date: Wed, 9 May 2007 21:49:20 +0200
User-agent: Mutt/1.5.15 (2007-04-06)

Hello!

Those of you who are old enough will remember that certain
kinds of implicit assumptions in programming used to raise
the outcry:

        All the world's a VAX!

E.g. taking for granted that a pointer will always fit into
an integer and vice versa.

After trying Qemu for the first time and a long debugging session
last weekend I'd like to suggest a new phrase for the current
millennium:

        If it ain't Windows, it must be Linux!


Please don't get me wrong, this is definitely not meant to be
an insult, but I got quite frustrated short of banging my head against
something. So, what happened?

I have an old license of Windows 98 SE lying around and I was seeking
a free way to run that on my old Powerbook G4. Luckily I own a fast
Intel iMac as well that I could use for setup and later compiling,
but the system was to run on the PowerPC CPU.
Reason was a single Windows application that I need. It talks to
my GPS receiver that I carry while paragliding via a serial port.

I first tried Bochs. While a appreciate the effort and even used
Bochs a couple of years ago to run Minix, it's far from usable
for any real work in Windows.

Next try: Qemu. Boy, was I surprised! Installing Windows 98 SE from
CD took less than two hours, perceived speed about a 486 or Pentium I,
quite usable. This was on the Intel iMac. Then I copied the finished
Windows installation to the G4. Still good. Really good. I love
the product.

OK, documentation says, to setup COM1 to be passed to a serial
port of the host system, add "-serial /dev/ttyXY". That was
/dev/cu.KeySerial1 for my Keyspan USB serial adapter.

This produced nothing but an error message like "could not open
/dev/cu.KeySerial1". This is when the debugging session started.
It ended to no avail. I'll spare you amount of times I looked
at the access bits of the device, tried if I could open it with
minicom and stuff like that, the workarounds with Unix
domain sockets instead of the tty and socat, ... the true reason
hit me like a hammer when I looked at the source of vl.c:

#if defined(__linux__)
        /* all the code that deals with ttys */
#endif

Wiiiiiiiiilmaaaaaaaaa!

Boys and girls, this code should run without modification on
_any_ sufficiently recent variant of Unix. _Unix_. That's a
whole class of operating systems adhering to certain API standards.
It even includes Linux, now, ain't that great?

And of course I proved it to run on Mac OS X in no time.

Da, zeerial port beink workink now.

So, please, please, please, don't make things that work perfectly
almost everywhere depend on Linux. Why would you?

End rant. Please don't take the tone too seriously. Now that I
can use the serial port without a hitch, I really like Qmemu.
All this was just so unnecessary.

Kind regards,
Patrick

P.S. No, I don't have a patch, because what I did locally does
     not fix the problem. Once we change

         #if defined(__linux__)
     to
         #if defined(__linux__) || defined(__DARWIN__)

     we will in no time have to add

         || defined(__FreeBSD__)
         ...
         ...

     ad nauseam.
-- 
punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
address@hidden       http://www.punkt.de
Gf: Jürgen Egeling      AG Mannheim 108285




reply via email to

[Prev in Thread] Current Thread [Next in Thread]