[Qemu-devel] [PATCH] [RFC] Syncing documentation vs. -help vs. qemu_options table v3

[Qemu-devel] [PATCH] [RFC] Syncing documentation vs. -help vs. qemu_options table v3

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 152 bytes --]

Hi,

This version uses a C tool to parse the options file instead of Perl
script. I also added HXCOMM for comment purposes.

Does this work on Windows?

[-- Attachment #2: option_system.diff.bz2 --]
[-- Type: application/x-bzip2, Size: 22701 bytes --]

Re: [Qemu-devel] [PATCH] [RFC] Syncing documentation vs. -help vs. qemu_options table v3

[Paul Brook]

On Tuesday 17 March 2009, Blue Swirl wrote:
> Hi,
>
> This version uses a C tool to parse the options file instead of Perl
> script. I also added HXCOMM for comment purposes.
>
> Does this work on Windows?

I'm pretty sure it doesn't work in cross environments.

Paul

Re: [Qemu-devel] [PATCH] [RFC] Syncing documentation vs. -help vs. qemu_options table v3

[Avi Kivity]

Paul Brook wrote:
>> This version uses a C tool to parse the options file instead of Perl
>> script. I also added HXCOMM for comment purposes.
>>
>> Does this work on Windows?
>>     
>
> I'm pretty sure it doesn't work in cross environments.
>   

Just have qemu-user run the thing.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] [PATCH] [RFC] Syncing documentation vs. -help vs. qemu_options table v3

[Paul Brook]

On Wednesday 18 March 2009, Avi Kivity wrote:
> Paul Brook wrote:
> >> This version uses a C tool to parse the options file instead of Perl
> >> script. I also added HXCOMM for comment purposes.
> >>
> >> Does this work on Windows?
> >
> > I'm pretty sure it doesn't work in cross environments.
>
> Just have qemu-user run the thing.

That's not going to work for several reasons:
- You might not be building qemu-user.
- qemu-user only supports a very small subset of systems. e.g. it's no use for 
linux->windows cross builds, which I expect to be the most common case
- The necessary runtime libraries might not be installed. Even if they are, 
qemu probably doesn't know where to find them.

Paul

Re: [Qemu-devel] [PATCH] [RFC] Syncing documentation vs. -help vs. qemu_options table v3

[Avi Kivity]

Paul Brook wrote:
>>>> This version uses a C tool to parse the options file instead of Perl
>>>> script. I also added HXCOMM for comment purposes.
>>>>
>>>> Does this work on Windows?
>>>>         
>>> I'm pretty sure it doesn't work in cross environments.
>>>       
>> Just have qemu-user run the thing.
>>     
>
> That's not going to work for several reasons:
> - You might not be building qemu-user.
> - qemu-user only supports a very small subset of systems. e.g. it's no use for 
> linux->windows cross builds, which I expect to be the most common case
> - The necessary runtime libraries might not be installed. Even if they are, 
> qemu probably doesn't know where to find them.
>   

That was not a serious suggestion.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Random thought about qemu-user and Windows

[Jamie Lokier]

Paul Brook wrote:
> - qemu-user only supports a very small subset of systems. e.g. it's
> no use for linux->windows cross builds, which I expect to be the
> most common case

Hmm...  I wonder how much would be required to emulate just the
Windows system calls (used by normal applications)?  I.e. the same way
qemu-user emulates the Linux and BSD system calls used by normal apps.

WINE does this, of course, but WINE is much bigger than that - it
replaces all the Windows userspace libraries.  That's much bigger than
just kernel behaviour.  I wonder how big the part needed just for
Windows system calls would be.

-- Jamie

Re: [Qemu-devel] Random thought about qemu-user and Windows

[Johannes Schindelin]

Hi,

On Thu, 19 Mar 2009, Jamie Lokier wrote:

> Paul Brook wrote:
> > - qemu-user only supports a very small subset of systems. e.g. it's
> > no use for linux->windows cross builds, which I expect to be the
> > most common case
> 
> Hmm...  I wonder how much would be required to emulate just the
> Windows system calls (used by normal applications)?  I.e. the same way
> qemu-user emulates the Linux and BSD system calls used by normal apps.
> 
> WINE does this, of course, but WINE is much bigger than that - it
> replaces all the Windows userspace libraries.  That's much bigger than
> just kernel behaviour.  I wonder how big the part needed just for
> Windows system calls would be.

You would still need all the proprietary libraries, such as kernel32.dll, 
user32.dll, ...

I guess, though, that the Ring3k project comes pretty close to emulating 
your idea: http://ring3k.org/

Keep in mind, translating syscalls from one architecture to another 
architecture is non-trivial (I once discussed this with a Solaris kernel 
developer, and he convinced me that it is a big task).

Ciao,
Dscho

Re: [Qemu-devel] Random thought about qemu-user and Windows

[Stuart Brady]

On Thu, Mar 19, 2009 at 11:50:15PM +0000, Jamie Lokier wrote:
> Hmm...  I wonder how much would be required to emulate just the
> Windows system calls (used by normal applications)?  I.e. the same way
> qemu-user emulates the Linux and BSD system calls used by normal apps.
> 
> WINE does this, of course, but WINE is much bigger than that - it
> replaces all the Windows userspace libraries.  That's much bigger than
> just kernel behaviour.  I wonder how big the part needed just for
> Windows system calls would be.

Hmm, at some point in the future, I suppose it's possible that there
could be a demand for something like FX!32 (which let you run i386 apps
on NT for DEC Alpha)...  x86 seems to be here to stay, though...

For most users, I suppose qemu+wine would (in theory) be want they want,
although perhaps it'd be possible to run some code (e.g. wineserver?)
directly on the host CPU, without any translation.
-- 
Stuart Brady

Re: [Qemu-devel] Random thought about qemu-user and Windows

[Andreas Färber]

Am 20.03.2009 um 21:18 schrieb Stuart Brady:

> On Thu, Mar 19, 2009 at 11:50:15PM +0000, Jamie Lokier wrote:
>> Hmm...  I wonder how much would be required to emulate just the
>> Windows system calls (used by normal applications)?  I.e. the same  
>> way
>> qemu-user emulates the Linux and BSD system calls used by normal  
>> apps.
>>
>> WINE does this, of course, but WINE is much bigger than that - it
>> replaces all the Windows userspace libraries.  That's much bigger  
>> than
>> just kernel behaviour.  I wonder how big the part needed just for
>> Windows system calls would be.
>
> Hmm, at some point in the future, I suppose it's possible that there
> could be a demand for something like FX!32 (which let you run i386  
> apps
> on NT for DEC Alpha)...  x86 seems to be here to stay, though...
>
> For most users, I suppose qemu+wine would (in theory) be want they  
> want,
> although perhaps it'd be possible to run some code (e.g. wineserver?)
> directly on the host CPU, without any translation.

Isn't that what ReactOS does when run through KVM, in a similar way to  
Haiku allowing to execute BeOS apps?

Andreas