* [Qemu-devel] RFC for new features
@ 2004-07-08 18:14 Fabrice Bellard
2004-07-08 18:46 ` [Qemu-devel] " Emmanuel Charpentier
` (8 more replies)
0 siblings, 9 replies; 50+ messages in thread
From: Fabrice Bellard @ 2004-07-08 18:14 UTC (permalink / raw)
To: qemu-devel
Hi,
As porting the SDL version to other OSes than Linux seems to become an
important issue, I plan to add the following features in the next days:
- Virtual console handled by SDL (Ctrl-Shift-F1 to get the guest screen,
Ctrl-Shift-F2 to get the monitor shell, and maybe Ctrl-Shift-F3 for
various logs).
- Support for more compressed and cow disk images formats so that
filesystems without hole support can use cow disk images too.
- New tool to create disk images, to compress them and to convert
between any disk image formats.
- Config file support (syntax: qemu mypc.qmu)
Comments ?
Fabrice.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Qemu-devel] Re: RFC for new features
2004-07-08 18:14 [Qemu-devel] RFC for new features Fabrice Bellard
@ 2004-07-08 18:46 ` Emmanuel Charpentier
2004-07-08 18:58 ` Antony T Curtis
` (2 more replies)
2004-07-08 18:54 ` [Qemu-devel] " Antony T Curtis
` (7 subsequent siblings)
8 siblings, 3 replies; 50+ messages in thread
From: Emmanuel Charpentier @ 2004-07-08 18:46 UTC (permalink / raw)
To: qemu-devel
Dear Fabrice,
First and foremost, thank you for this marvelmous piece of work !
Fabrice Bellard wrote:
> Hi,
>
> As porting the SDL version to other OSes than Linux seems to become an
> important issue, I plan to add the following features in the next days:
>
> - Virtual console handled by SDL (Ctrl-Shift-F1 to get the guest screen,
> Ctrl-Shift-F2 to get the monitor shell, and maybe Ctrl-Shift-F3 for
> various logs).
I fail to see the point for use in a GUI. Maybe for "autonomous" screens (à
la Linux virtual consoles) ?
> - Support for more compressed and cow disk images formats so that
> filesystems without hole support can use cow disk images too.
Nice idea ! Maybe also support for raw devices (dedicating a full HD to a
given guest OS might be quite justifiable in some setups...) ?
> - New tool to create disk images, to compress them and to convert
> between any disk image formats.
Corrolary of the previous one.
> - Config file support (syntax: qemu mypc.qmu)
This one is *the* most important ! enables easy use and configuration by
non-technical users (hint : use an easily-parsed format, allowing for GUI
frontends).
> Comments ?
I have some further ideas, which need to grow up a bit before public
exposure. Furthermore, I'm still at odds with some difficulties with the
current version (CVS from end June), that I want to solve before asking for
more ...
Emmanuel Charpentier
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] Re: RFC for new features
2004-07-08 18:46 ` [Qemu-devel] " Emmanuel Charpentier
@ 2004-07-08 18:58 ` Antony T Curtis
2004-07-08 19:05 ` Julian Seward
2004-07-08 19:47 ` Jim C. Brown
2 siblings, 0 replies; 50+ messages in thread
From: Antony T Curtis @ 2004-07-08 18:58 UTC (permalink / raw)
To: qemu-devel
On Thu, 2004-07-08 at 19:46, Emmanuel Charpentier wrote:
<snip>
> > - Support for more compressed and cow disk images formats so that
> > filesystems without hole support can use cow disk images too.
>
> Nice idea ! Maybe also support for raw devices (dedicating a full HD to a
> given guest OS might be quite justifiable in some setups...) ?
Hmm... I am already able to use raw devices, both CDROM and Hard disks.
One of the fun things I do is to boot FreeBSD Guest off a COW backed
against the same partition that the FreeBSD Host is running.
--
Antony T Curtis <antony.t.curtis@ntlworld.com>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] Re: RFC for new features
2004-07-08 18:46 ` [Qemu-devel] " Emmanuel Charpentier
2004-07-08 18:58 ` Antony T Curtis
@ 2004-07-08 19:05 ` Julian Seward
2004-07-08 19:47 ` Jim C. Brown
2 siblings, 0 replies; 50+ messages in thread
From: Julian Seward @ 2004-07-08 19:05 UTC (permalink / raw)
To: qemu-devel; +Cc: Emmanuel Charpentier
> Emmanuel Charpentier wrote:
>
> Fabrice Bellard wrote:
> > Hi,
> >
> > As porting the SDL version to other OSes than Linux seems to become an
> > important issue, I plan to add the following features in the next days:
> >
> > - Virtual console handled by SDL (Ctrl-Shift-F1 to get the guest screen,
> > Ctrl-Shift-F2 to get the monitor shell, and maybe Ctrl-Shift-F3 for
> > various logs).
Good idea. Yes.
> > - Support for more compressed and cow disk images formats so that
> > filesystems without hole support can use cow disk images too.
Well, maybe, but not critical.
> I'm still at odds with some difficulties with the
> current version (CVS from end June), that I want to solve before asking for
> more ...
I agree. Fabrice, it would be good to do a stable 0.5.6 release
before moving on to this new stuff. It's been quite a while
since 0.5.5 -- almost 2 months -- and I get the impression that quite
a lot has improved in that time.
J
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] Re: RFC for new features
2004-07-08 18:46 ` [Qemu-devel] " Emmanuel Charpentier
2004-07-08 18:58 ` Antony T Curtis
2004-07-08 19:05 ` Julian Seward
@ 2004-07-08 19:47 ` Jim C. Brown
2 siblings, 0 replies; 50+ messages in thread
From: Jim C. Brown @ 2004-07-08 19:47 UTC (permalink / raw)
To: qemu-devel
On Thu, Jul 08, 2004 at 08:46:47PM +0200, Emmanuel Charpentier wrote:
> >- Config file support (syntax: qemu mypc.qmu)
>
> This one is *the* most important ! enables easy use and configuration by
> non-technical users (hint : use an easily-parsed format, allowing for GUI
> frontends).
>
> Emmanuel Charpentier
You can have that now. The shell script called vqemu makes using a configuration
file for qemu easy. It just uses the config file to figure out which command
line parameters to pass to qemu. (I'd expect the .qmu config file to be more
bochs-like myself (the inability to change the default IRQ/IO addrs can be
frustrating when installing a new OS in qemu for the first time).) The caveat
is that the shell script won't work in Windows unless (maybe) you use Cygwin bash.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 18:14 [Qemu-devel] RFC for new features Fabrice Bellard
2004-07-08 18:46 ` [Qemu-devel] " Emmanuel Charpentier
@ 2004-07-08 18:54 ` Antony T Curtis
2004-07-08 19:36 ` Jim C. Brown
2004-07-08 19:45 ` Jocelyn Mayer
2004-07-08 19:00 ` Karel Gardas
` (6 subsequent siblings)
8 siblings, 2 replies; 50+ messages in thread
From: Antony T Curtis @ 2004-07-08 18:54 UTC (permalink / raw)
To: qemu-devel
On Thu, 2004-07-08 at 19:14, Fabrice Bellard wrote:
> Hi,
>
> As porting the SDL version to other OSes than Linux seems to become an
> important issue, I plan to add the following features in the next days:
>
> - Virtual console handled by SDL (Ctrl-Shift-F1 to get the guest screen,
> Ctrl-Shift-F2 to get the monitor shell, and maybe Ctrl-Shift-F3 for
> various logs).
sounds nice ... but there are a number of benefits with having the
monitor shell as is...
> - Support for more compressed and cow disk images formats so that
> filesystems without hole support can use cow disk images too.
>
> - New tool to create disk images, to compress them and to convert
> between any disk image formats.
These sounds great
> - Config file support (syntax: qemu mypc.qmu)
It would be a nice feature if the hw devices can be dynamically loaded
and 'installed' as per the config file.
> Comments ?
>
> Fabrice.
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> FLAGS (\Seen))
--
Antony T Curtis <antony.t.curtis@ntlworld.com>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 18:54 ` [Qemu-devel] " Antony T Curtis
@ 2004-07-08 19:36 ` Jim C. Brown
2004-07-08 20:31 ` Jernej Simončič
2004-07-08 19:45 ` Jocelyn Mayer
1 sibling, 1 reply; 50+ messages in thread
From: Jim C. Brown @ 2004-07-08 19:36 UTC (permalink / raw)
To: qemu-devel
On Thu, Jul 08, 2004 at 07:54:46PM +0100, Antony T Curtis wrote:
> On Thu, 2004-07-08 at 19:14, Fabrice Bellard wrote:
> > Hi,
> >
> > As porting the SDL version to other OSes than Linux seems to become an
> > important issue, I plan to add the following features in the next days:
> >
> > - Virtual console handled by SDL (Ctrl-Shift-F1 to get the guest screen,
> > Ctrl-Shift-F2 to get the monitor shell, and maybe Ctrl-Shift-F3 for
> > various logs).
>
> sounds nice ... but there are a number of benefits with having the
> monitor shell as is...
I agree. Perhaps on Linux this could be optional (i.e. with '-console-monitor'
you get the old monitor, but on hosts that dont support those (i.e. Windows)
that option would be ignored).
> > - Config file support (syntax: qemu mypc.qmu)
>
> It would be a nice feature if the hw devices can be dynamically loaded
> and 'installed' as per the config file.
Yes. I have a script that gives qemu config file support, but all it does is
wrap the command line parameters. (It is still very useful and I'll probably
keep it alive since it has a few things in it that qemu prolly wont, such as
support for using vdeq.)
>
> > Comments ?
> >
> > Fabrice.
> >
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> > FLAGS (\Seen))
> --
> Antony T Curtis <antony.t.curtis@ntlworld.com>
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 19:36 ` Jim C. Brown
@ 2004-07-08 20:31 ` Jernej Simončič
2004-07-08 21:04 ` Jim C. Brown
0 siblings, 1 reply; 50+ messages in thread
From: Jernej Simončič @ 2004-07-08 20:31 UTC (permalink / raw)
To: Jim C. Brown on [qemu-devel]
On Thursday, July 8, 2004, 21:36:44, Jim C. Brown wrote:
> I agree. Perhaps on Linux this could be optional (i.e. with '-console-monitor'
> you get the old monitor, but on hosts that dont support those (i.e. Windows)
> that option would be ignored).
Windows has console support - and the program doesn't have to be compiled
for console to use it (just look at eg. Gimp - starts with no console, and
if there are problems [or, if you eg. use --verbose switch], a console is
open - but only if you didn't redirect stdout and stderr).
--
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >
When the going gets tough, everybody leaves.
-- Lynch's Law
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 20:31 ` Jernej Simončič
@ 2004-07-08 21:04 ` Jim C. Brown
2004-07-08 22:37 ` Jernej Simončič
2004-07-08 23:40 ` OT: Re: [Qemu-devel] RFC for new features Antony T Curtis
0 siblings, 2 replies; 50+ messages in thread
From: Jim C. Brown @ 2004-07-08 21:04 UTC (permalink / raw)
To: qemu-devel
On Thu, Jul 08, 2004 at 10:31:10PM +0200, Jernej Simon?i? wrote:
> On Thursday, July 8, 2004, 21:36:44, Jim C. Brown wrote:
>
> > I agree. Perhaps on Linux this could be optional (i.e. with '-console-monitor'
> > you get the old monitor, but on hosts that dont support those (i.e. Windows)
> > that option would be ignored).
>
> Windows has console support - and the program doesn't have to be compiled
> for console to use it (just look at eg. Gimp - starts with no console, and
> if there are problems [or, if you eg. use --verbose switch], a console is
> open - but only if you didn't redirect stdout and stderr).
For 9x this isn't true unless the program uses the console subsystem. So a
regular GUI program has no console.
In any case, this is moving away from my original point: I prefer the old behavior.
The first is that I find it convient to be able to switch between the monitor (in
an xterm) and the SDL window just by clicking. The second is that one can redirect
qemu's input/output (and thus redirect the monitor) which makes hooking into
the monitor (from perhaps a GUI wrapper - I am told that is what qemu workstation
does) trivial.
>
> --
> < Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >
>
> When the going gets tough, everybody leaves.
> -- Lynch's Law
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 21:04 ` Jim C. Brown
@ 2004-07-08 22:37 ` Jernej Simončič
2004-07-08 22:57 ` Jim C. Brown
2004-07-09 0:15 ` [Qemu-devel] RFC for new features (Console under Windows) Filip Navara
2004-07-08 23:40 ` OT: Re: [Qemu-devel] RFC for new features Antony T Curtis
1 sibling, 2 replies; 50+ messages in thread
From: Jernej Simončič @ 2004-07-08 22:37 UTC (permalink / raw)
To: Jim C. Brown on [qemu-devel]
On Thursday, July 8, 2004, 23:04:41, Jim C. Brown wrote:
> For 9x this isn't true unless the program uses the console subsystem. So a
> regular GUI program has no console.
Gimp (or, to be more precise GTK+/GLib) somehow get around this limit - I
installed Windows 98 in qemu just to reconfirm, and when run normally, there
is no console, but if you add the --verbose switch (or, if an error occurs),
a console Window is opened.
--
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >
Only God can make a random selection.
-- Levy's Ninth Law of the Disillusionment of the True Liberal
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 22:37 ` Jernej Simončič
@ 2004-07-08 22:57 ` Jim C. Brown
2004-07-09 0:15 ` [Qemu-devel] RFC for new features (Console under Windows) Filip Navara
1 sibling, 0 replies; 50+ messages in thread
From: Jim C. Brown @ 2004-07-08 22:57 UTC (permalink / raw)
To: qemu-devel
On Fri, Jul 09, 2004 at 12:37:59AM +0200, Jernej Simon?i? wrote:
> On Thursday, July 8, 2004, 23:04:41, Jim C. Brown wrote:
>
> > For 9x this isn't true unless the program uses the console subsystem. So a
> > regular GUI program has no console.
>
> Gimp (or, to be more precise GTK+/GLib) somehow get around this limit - I
> installed Windows 98 in qemu just to reconfirm, and when run normally, there
> is no console, but if you add the --verbose switch (or, if an error occurs),
> a console Window is opened.
>
So we are agreed then: We like the old monitor and we want to keep it.
> --
> < Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >
>
> Only God can make a random selection.
> -- Levy's Ninth Law of the Disillusionment of the True Liberal
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features (Console under Windows)
2004-07-08 22:37 ` Jernej Simončič
2004-07-08 22:57 ` Jim C. Brown
@ 2004-07-09 0:15 ` Filip Navara
1 sibling, 0 replies; 50+ messages in thread
From: Filip Navara @ 2004-07-09 0:15 UTC (permalink / raw)
To: qemu-devel
Jernej Simončič wrote:
>On Thursday, July 8, 2004, 23:04:41, Jim C. Brown wrote:
>
>
>
>>For 9x this isn't true unless the program uses the console subsystem. So a
>>regular GUI program has no console.
>>
>>
>
>Gimp (or, to be more precise GTK+/GLib) somehow get around this limit - I
>installed Windows 98 in qemu just to reconfirm, and when run normally, there
>is no console, but if you add the --verbose switch (or, if an error occurs),
>a console Window is opened.
>
This isn't problem at all, you can use the AllocConsole or AttachConsole
API calls, but I think that's not needed. I still have a patch on my HDD
that makes QEMU a console application and fixes the keyboard input (to
the monitor) on Windows, but I doubt it would apply cleanly to current CVS.
Regards,
Filip
^ permalink raw reply [flat|nested] 50+ messages in thread
* OT: Re: [Qemu-devel] RFC for new features
2004-07-08 21:04 ` Jim C. Brown
2004-07-08 22:37 ` Jernej Simončič
@ 2004-07-08 23:40 ` Antony T Curtis
1 sibling, 0 replies; 50+ messages in thread
From: Antony T Curtis @ 2004-07-08 23:40 UTC (permalink / raw)
To: qemu-devel
On Thu, 2004-07-08 at 22:04, Jim C. Brown wrote:
> On Thu, Jul 08, 2004 at 10:31:10PM +0200, Jernej Simon?i? wrote:
> > On Thursday, July 8, 2004, 21:36:44, Jim C. Brown wrote:
> >
> > > I agree. Perhaps on Linux this could be optional (i.e. with '-console-monitor'
> > > you get the old monitor, but on hosts that dont support those (i.e. Windows)
> > > that option would be ignored).
> >
> > Windows has console support - and the program doesn't have to be compiled
> > for console to use it (just look at eg. Gimp - starts with no console, and
> > if there are problems [or, if you eg. use --verbose switch], a console is
> > open - but only if you didn't redirect stdout and stderr).
>
> For 9x this isn't true unless the program uses the console subsystem. So a
> regular GUI program has no console.
Reminds me of my OS/2 days... a PM (GUI) app doesn't have a console....
And a console app cannot open windows. But there is a hack (involves
writing to undocumented data) which allows a console app have windows. I
discovered this by accident and used it for a native OS/2 Xlib
implementation (Xlib->OS/2 GDI, may be googled by keyword "everblue")
> In any case, this is moving away from my original point: I prefer the old behavior.
> The first is that I find it convient to be able to switch between the monitor (in
> an xterm) and the SDL window just by clicking. The second is that one can redirect
> qemu's input/output (and thus redirect the monitor) which makes hooking into
> the monitor (from perhaps a GUI wrapper - I am told that is what qemu workstation
> does) trivial.
>
> >
> > --
> > < Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >
> >
> > When the going gets tough, everybody leaves.
> > -- Lynch's Law
> >
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Antony T Curtis <antony.t.curtis@ntlworld.com>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 18:54 ` [Qemu-devel] " Antony T Curtis
2004-07-08 19:36 ` Jim C. Brown
@ 2004-07-08 19:45 ` Jocelyn Mayer
1 sibling, 0 replies; 50+ messages in thread
From: Jocelyn Mayer @ 2004-07-08 19:45 UTC (permalink / raw)
To: qemu mailing list
On Thu, 2004-07-08 at 20:54, Antony T Curtis wrote:
> On Thu, 2004-07-08 at 19:14, Fabrice Bellard wrote:
> > Hi,
> >
> > As porting the SDL version to other OSes than Linux seems to become an
> > important issue, I plan to add the following features in the next days:
> >
> > - Virtual console handled by SDL (Ctrl-Shift-F1 to get the guest screen,
> > Ctrl-Shift-F2 to get the monitor shell, and maybe Ctrl-Shift-F3 for
> > various logs).
Great !
I'd also like to have a "device interface" to be able to create and use
a new console, mainly for BIOS output and debug without having to use a
serial port or qemu monitor.
[...]
> > - Config file support (syntax: qemu mypc.qmu)
>
> It would be a nice feature if the hw devices can be dynamically loaded
> and 'installed' as per the config file.
Sounds great only if the whole configuration can be overriden using the
command line. It's a real pain having to edit config files everytime you
need to change a parameter for testing...
But why mypc ? my_hw is more appropriate :-))
--
Jocelyn Mayer <l_indien@magic.fr>
Never organized
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 18:14 [Qemu-devel] RFC for new features Fabrice Bellard
2004-07-08 18:46 ` [Qemu-devel] " Emmanuel Charpentier
2004-07-08 18:54 ` [Qemu-devel] " Antony T Curtis
@ 2004-07-08 19:00 ` Karel Gardas
2004-07-08 21:44 ` vaise
2004-07-08 19:30 ` Jean-Michel POURE
` (5 subsequent siblings)
8 siblings, 1 reply; 50+ messages in thread
From: Karel Gardas @ 2004-07-08 19:00 UTC (permalink / raw)
To: qemu-devel
On Thu, 8 Jul 2004, Fabrice Bellard wrote:
> Comments ?
I would like to see qemu faster in system emulation of x86 on x86 -- if it
is ever possible -- vide my email in archive about speed of compilation on
x86/solaris9 on x86 host.
Thanks,
Karel
--
Karel Gardas kgardas@objectsecurity.com
ObjectSecurity Ltd. http://www.objectsecurity.com
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 19:00 ` Karel Gardas
@ 2004-07-08 21:44 ` vaise
0 siblings, 0 replies; 50+ messages in thread
From: vaise @ 2004-07-08 21:44 UTC (permalink / raw)
To: qemu-devel
On Thursday 08 July 2004 21:00, Karel Gardas wrote:
> I would like to see qemu faster in system emulation of x86 on x86 -- if it
> is ever possible
This is the most important thing for me too. I know it is not easy. But it
could be done by Little steps.
On Thursday 08 July 2004 21:05, Julian Seward wrote:
> I agree. Fabrice, it would be good to do a stable 0.5.6 release
> before moving on to this new stuff. It's been quite a while
> since 0.5.5 -- almost 2 months -- and I get the impression that quite
> a lot has improved in that time.
I agree too.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 18:14 [Qemu-devel] RFC for new features Fabrice Bellard
` (2 preceding siblings ...)
2004-07-08 19:00 ` Karel Gardas
@ 2004-07-08 19:30 ` Jean-Michel POURE
2004-07-08 19:48 ` Brad Watson
` (4 subsequent siblings)
8 siblings, 0 replies; 50+ messages in thread
From: Jean-Michel POURE @ 2004-07-08 19:30 UTC (permalink / raw)
To: qemu-devel
> Comments ?
Sounds great. These features will probably benefit FreeOSZoo users a lot.
When testing QEMU under Windows, it seemed like there was no CD-ROM access in
qemu.exe. Are there plans or existing patches to access CD-ROM in the Windows
port of QEMU?
Regards, Jean-Michel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 18:14 [Qemu-devel] RFC for new features Fabrice Bellard
` (3 preceding siblings ...)
2004-07-08 19:30 ` Jean-Michel POURE
@ 2004-07-08 19:48 ` Brad Watson
2004-07-08 21:37 ` Jan Dittmer
` (3 subsequent siblings)
8 siblings, 0 replies; 50+ messages in thread
From: Brad Watson @ 2004-07-08 19:48 UTC (permalink / raw)
To: qemu-devel
Hi Fabrice,
XML format for the config file ?
Device emulation with code virtualization for x86 on
x86 and ppc on ppc (ala lillyvm, colinux like
techniques, or ??? ) ?
Thanks again to you, and everyone else that has
contributed to this project for all of your excellent
work.
Regards,
Brad Watson
--- Fabrice Bellard <fabrice@bellard.org> wrote:
> Hi,
>
> As porting the SDL version to other OSes than Linux
> seems to become an
> important issue, I plan to add the following
> features in the next days:
>
> - Virtual console handled by SDL (Ctrl-Shift-F1 to
> get the guest screen,
> Ctrl-Shift-F2 to get the monitor shell, and maybe
> Ctrl-Shift-F3 for
> various logs).
>
> - Support for more compressed and cow disk images
> formats so that
> filesystems without hole support can use cow disk
> images too.
>
> - New tool to create disk images, to compress them
> and to convert
> between any disk image formats.
>
> - Config file support (syntax: qemu mypc.qmu)
>
> Comments ?
>
> Fabrice.
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 18:14 [Qemu-devel] RFC for new features Fabrice Bellard
` (4 preceding siblings ...)
2004-07-08 19:48 ` Brad Watson
@ 2004-07-08 21:37 ` Jan Dittmer
2004-07-08 22:24 ` malc
` (2 subsequent siblings)
8 siblings, 0 replies; 50+ messages in thread
From: Jan Dittmer @ 2004-07-08 21:37 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 330 bytes --]
Fabrice Bellard wrote:
> Hi,
>
> As porting the SDL version to other OSes than Linux seems to become an
> important issue, I plan to add the following features in the next days:
Booting Windows XP (see my mail from earlier this week on the mailing
list). I could really need some guidance for troubleshooting...
Thanks,
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 18:14 [Qemu-devel] RFC for new features Fabrice Bellard
` (5 preceding siblings ...)
2004-07-08 21:37 ` Jan Dittmer
@ 2004-07-08 22:24 ` malc
2004-07-08 19:35 ` Jim C. Brown
2004-07-09 20:27 ` [Qemu-devel] " Emmanuel Charpentier
2004-07-09 21:51 ` [Qemu-devel] (Before) " Hetz Ben Hamo
8 siblings, 1 reply; 50+ messages in thread
From: malc @ 2004-07-08 22:24 UTC (permalink / raw)
To: qemu-devel
On Thu, 8 Jul 2004, Fabrice Bellard wrote:
> Hi,
>
> As porting the SDL version to other OSes than Linux seems to become an
> important issue, I plan to add the following features in the next days:
>
> - Virtual console handled by SDL (Ctrl-Shift-F1 to get the guest screen,
> Ctrl-Shift-F2 to get the monitor shell, and maybe Ctrl-Shift-F3 for
> various logs).
>
> - Support for more compressed and cow disk images formats so that
> filesystems without hole support can use cow disk images too.
>
> - New tool to create disk images, to compress them and to convert
> between any disk image formats.
>
> - Config file support (syntax: qemu mypc.qmu)
If it would have some sort of generic interface for devices.
(Though i must say that prunanciation of `qmu' puzzles me)
--
mailto:malc@pulsesoft.com
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 22:24 ` malc
@ 2004-07-08 19:35 ` Jim C. Brown
0 siblings, 0 replies; 50+ messages in thread
From: Jim C. Brown @ 2004-07-08 19:35 UTC (permalink / raw)
To: qemu-devel
On Thu, Jul 08, 2004 at 10:24:14PM +0000, malc wrote:
> > - Config file support (syntax: qemu mypc.qmu)
>
> If it would have some sort of generic interface for devices.
> (Though i must say that prunanciation of `qmu' puzzles me)
What do you mean by 'generic interface' ? The ability to set the IRQ/IOMEM/DMA
of various devices (NE2K, SB16, etc)? That would be very useful.
qmu looks like Q - Mu to me (where Q is the letter Q and Mu is the Greek letter
mu).
>
> --
> mailto:malc@pulsesoft.com
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Qemu-devel] Re: RFC for new features
2004-07-08 18:14 [Qemu-devel] RFC for new features Fabrice Bellard
` (6 preceding siblings ...)
2004-07-08 22:24 ` malc
@ 2004-07-09 20:27 ` Emmanuel Charpentier
2004-07-09 22:13 ` Antony T Curtis
2004-07-09 21:51 ` [Qemu-devel] (Before) " Hetz Ben Hamo
8 siblings, 1 reply; 50+ messages in thread
From: Emmanuel Charpentier @ 2004-07-09 20:27 UTC (permalink / raw)
To: qemu-devel
Fabrice Bellard wrote:
[ that he wants our whishlists before porting the SDL version to other
platforms. ]
Well, I have some wishes, but I'm not sure they fit well in your current
worplans. Please feel free to discard them :
1) There are still some CPU emulation issues ; I can't diagnose them but I
can prove that they exist :
After Win2k installation (whatever version), I have been unable to install
Mozilla 1.6. I have been able to install Mozilla 1.7, though. Windows being
... well, Windows, I've been unable to locate error logs. Go figure ...
It tool me 4 trials to find a Win2k version that would allow for the
installation of Office 2000. I tried to install Office 97 twice, with no
luck. I didn't retry with the "correct" installation of Win2k.
The SP4 patch doesn't install (error a short while after unpacking)
The "disk full" issue while installing Win2k still happens every time.
None of this happens using the very same files/disks while installing on
real hardware.
2) There are device emulation issues :
The current cirrusvga is a vast improvement over the previous bochs
device. However, pushing available memory to more than 4 Mb wold allow for
better resolutions : 1024x768x16 is a bit limiting in some uses.
There are still serious issues with audio emulation. The current SB16/AXE
device can do simple things (playing the "opening" .wav file, etc ...), but
trying to install Dragon voice recognition still fails very early (at the
first sound that the installer tries to play), and crashes the whole
emulation (the graphics window diseappear, and you're left with no mouse).
3) I still think that a virtualizer based on QEMU, while quite a bit more
limited in scope than QEMU itself, would be extremely useful : letting
user-level code not touching hardware run native and trapping anything
related to I/O, memory-mapped I/O or changing protection level (allowing to
run *that* on the emulated CPU) would allow for a nice acceleration. This
would be a boon for all the people using QEMU to run hardware available for
their CPU but not their platform (think Windows user running Linux/FreeBSD
software and vice-versa), which may well be a majority among qemu users.
None of this is absolutely critical, and QEMU is already *extremely*
useable (and useful ! ) as it is. The most critical are probably the CPU
emulation issues, the least the virtualizer.
Hope this helps,
Emmanuel Charpentier
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] Re: RFC for new features
2004-07-09 20:27 ` [Qemu-devel] " Emmanuel Charpentier
@ 2004-07-09 22:13 ` Antony T Curtis
2004-07-10 0:38 ` Derek Fawcus
` (2 more replies)
0 siblings, 3 replies; 50+ messages in thread
From: Antony T Curtis @ 2004-07-09 22:13 UTC (permalink / raw)
To: qemu-devel
On Fri, 2004-07-09 at 21:27, Emmanuel Charpentier wrote:
> Fabrice Bellard wrote:
>
> [ that he wants our whishlists before porting the SDL version to other
> platforms. ]
>
> Well, I have some wishes, but I'm not sure they fit well in your current
> worplans. Please feel free to discard them :
>
> 1) There are still some CPU emulation issues ; I can't diagnose them but I
> can prove that they exist :
> After Win2k installation (whatever version), I have been unable to install
> Mozilla 1.6. I have been able to install Mozilla 1.7, though. Windows being
> .. well, Windows, I've been unable to locate error logs. Go figure ...
> It tool me 4 trials to find a Win2k version that would allow for the
> installation of Office 2000. I tried to install Office 97 twice, with no
> luck. I didn't retry with the "correct" installation of Win2k.
> The SP4 patch doesn't install (error a short while after unpacking)
> The "disk full" issue while installing Win2k still happens every time.
>
> None of this happens using the very same files/disks while installing on
> real hardware.
Yes - I think that there are instances where the simulation is wrong...
OS/2 Warp 3 seems to suffer from GPFs when running applications
consistantly and repeatably.
> 2) There are device emulation issues :
> The current cirrusvga is a vast improvement over the previous bochs
> device. However, pushing available memory to more than 4 Mb wold allow for
> better resolutions : 1024x768x16 is a bit limiting in some uses.
> There are still serious issues with audio emulation. The current SB16/AXE
> device can do simple things (playing the "opening" .wav file, etc ...), but
> trying to install Dragon voice recognition still fails very early (at the
> first sound that the installer tries to play), and crashes the whole
> emulation (the graphics window diseappear, and you're left with no mouse).
Well - the CL-GD544X chips can only handle 4MB of memory, maximum. For
larger framebuffers, we would have to emulate a different video chip -
If we wish to stick to Cirrus Logic, The Laguna CL-GD546x chips can
address up to 16MB I think.... Of course, there are many other chips - I
think perhaps the Tseng Labs ET6000 may be simple enough to simulate and
would support a larger framebuffer.
> 3) I still think that a virtualizer based on QEMU, while quite a bit more
> limited in scope than QEMU itself, would be extremely useful : letting
> user-level code not touching hardware run native and trapping anything
> related to I/O, memory-mapped I/O or changing protection level (allowing to
> run *that* on the emulated CPU) would allow for a nice acceleration. This
> would be a boon for all the people using QEMU to run hardware available for
> their CPU but not their platform (think Windows user running Linux/FreeBSD
> software and vice-versa), which may well be a majority among qemu users.
Hmm... If a virtualizer is what is wanted, there are several options
already available... "Xen" is supposedly very good.
I think QEmu's strength is that it is not a virtualizer - it is a system
simulator.
Perhaps work can be done to get better performance when simulating the a
similar system to the host... but perhaps there would be more real
benefit in attemting to make the translator optimise the code it
generates... LUA has already been mentioned as a possible alternative
code generator.
> None of this is absolutely critical, and QEMU is already *extremely*
> useable (and useful ! ) as it is. The most critical are probably the CPU
> emulation issues, the least the virtualizer.
>
> Hope this helps,
>
> Emmanuel Charpentier
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> FLAGS (\Seen))
--
Antony T Curtis <antony.t.curtis@ntlworld.com>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] Re: RFC for new features
2004-07-09 22:13 ` Antony T Curtis
@ 2004-07-10 0:38 ` Derek Fawcus
2004-07-10 2:44 ` [Qemu-devel] 3Dfx... Just guessing Natalia Portillo
2004-07-11 4:45 ` Re[2]: [Qemu-devel] Re: RFC for new features Igor Shmukler
2 siblings, 0 replies; 50+ messages in thread
From: Derek Fawcus @ 2004-07-10 0:38 UTC (permalink / raw)
To: qemu-devel
On Fri, Jul 09, 2004 at 11:13:30PM +0100, Antony T Curtis wrote:
> > 2) There are device emulation issues :
> > The current cirrusvga is a vast improvement over the previous bochs
> > device. However, pushing available memory to more than 4 Mb wold allow for
> > better resolutions : 1024x768x16 is a bit limiting in some uses.
Huh - I don't think there are any specific pitch restrictions on this chipset.
4M should allow 1280x1024@24bpp (or 1152x864@32bpp). Is that not enougth?
> Well - the CL-GD544X chips can only handle 4MB of memory, maximum. For
> larger framebuffers, we would have to emulate a different video chip -
> If we wish to stick to Cirrus Logic, The Laguna CL-GD546x chips can
> address up to 16MB I think....
Nope. Only 8M. The architecture has scope for 2 RAMBUS channels, but they
only implemented chips with 1 RAMBUS channel. One of the fields in the
channel control register is 3 bits, identifying the number of 1M ram banks
available... (Someone who has spent too long playing with Laguna chips).
Besides, the Laguna is a more complex beast with a 3 operand BitBLT engine...
DF
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Qemu-devel] 3Dfx... Just guessing
2004-07-09 22:13 ` Antony T Curtis
2004-07-10 0:38 ` Derek Fawcus
@ 2004-07-10 2:44 ` Natalia Portillo
2004-07-10 13:06 ` Fabrice Bellard
2004-07-11 1:10 ` Jim C. Brown
2004-07-11 4:45 ` Re[2]: [Qemu-devel] Re: RFC for new features Igor Shmukler
2 siblings, 2 replies; 50+ messages in thread
From: Natalia Portillo @ 2004-07-10 2:44 UTC (permalink / raw)
To: qemu-devel
Hi.
I'm just thinkig...
Guessing...
Is it possible to emulate a 3Dfx chip?
There are available documents, etc?
The 3Dfx are the most supported 3D cards.
Have drivers for DOS, Windows, MacOS, Linux, BSD, any system where XFree86
works, etc.
But I think that nVidia has "ghosted" all available information, as they did
with the 3Dfx webpage and drivers. :(
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] 3Dfx... Just guessing
2004-07-10 2:44 ` [Qemu-devel] 3Dfx... Just guessing Natalia Portillo
@ 2004-07-10 13:06 ` Fabrice Bellard
2004-07-10 20:41 ` Natalia Portillo
2004-07-11 1:10 ` Jim C. Brown
1 sibling, 1 reply; 50+ messages in thread
From: Fabrice Bellard @ 2004-07-10 13:06 UTC (permalink / raw)
To: qemu-devel
SiS6326 seems a better choice because it is documented and well
supported. It was my target before I improved the submitted Cirrus patch.
Fabrice.
Natalia Portillo wrote:
> Hi.
>
> I'm just thinkig...
> Guessing...
>
> Is it possible to emulate a 3Dfx chip?
> There are available documents, etc?
>
> The 3Dfx are the most supported 3D cards.
> Have drivers for DOS, Windows, MacOS, Linux, BSD, any system where XFree86
> works, etc.
>
> But I think that nVidia has "ghosted" all available information, as they did
> with the 3Dfx webpage and drivers. :(
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [Qemu-devel] 3Dfx... Just guessing
2004-07-10 13:06 ` Fabrice Bellard
@ 2004-07-10 20:41 ` Natalia Portillo
2004-07-11 21:20 ` Ishwar Rattan
0 siblings, 1 reply; 50+ messages in thread
From: Natalia Portillo @ 2004-07-10 20:41 UTC (permalink / raw)
To: qemu-devel
Well I wans't proposing 3Dfx for be emulated, but just asking if it is
possible and if there is the documentation.
> -----Mensaje original-----
> De: qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org
> [mailto:qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org]
> En nombre de Fabrice Bellard
> Enviado el: sábado, 10 de julio de 2004 14:07
> Para: qemu-devel@nongnu.org
> Asunto: Re: [Qemu-devel] 3Dfx... Just guessing
>
> SiS6326 seems a better choice because it is documented and
> well supported. It was my target before I improved the
> submitted Cirrus patch.
>
> Fabrice.
>
> Natalia Portillo wrote:
> > Hi.
> >
> > I'm just thinkig...
> > Guessing...
> >
> > Is it possible to emulate a 3Dfx chip?
> > There are available documents, etc?
> >
> > The 3Dfx are the most supported 3D cards.
> > Have drivers for DOS, Windows, MacOS, Linux, BSD, any system where
> > XFree86 works, etc.
> >
> > But I think that nVidia has "ghosted" all available information, as
> > they did with the 3Dfx webpage and drivers. :(
> >
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >
>
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] 3Dfx... Just guessing
2004-07-10 2:44 ` [Qemu-devel] 3Dfx... Just guessing Natalia Portillo
2004-07-10 13:06 ` Fabrice Bellard
@ 2004-07-11 1:10 ` Jim C. Brown
2004-07-11 11:16 ` Gianni Tedesco
1 sibling, 1 reply; 50+ messages in thread
From: Jim C. Brown @ 2004-07-11 1:10 UTC (permalink / raw)
To: qemu-devel
On Sat, Jul 10, 2004 at 03:44:13AM +0100, Natalia Portillo wrote:
> Hi.
>
> I'm just thinkig...
> Guessing...
>
> Is it possible to emulate a 3Dfx chip?
> There are available documents, etc?
>
> The 3Dfx are the most supported 3D cards.
> Have drivers for DOS, Windows, MacOS, Linux, BSD, any system where XFree86
> works, etc.
>
> But I think that nVidia has "ghosted" all available information, as they did
> with the 3Dfx webpage and drivers. :(
>
>
I have a PCI 3Dfx chip, so if we go this route I may be able to help.
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] 3Dfx... Just guessing
2004-07-11 1:10 ` Jim C. Brown
@ 2004-07-11 11:16 ` Gianni Tedesco
0 siblings, 0 replies; 50+ messages in thread
From: Gianni Tedesco @ 2004-07-11 11:16 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
On Sat, 2004-07-10 at 21:10 -0400, Jim C. Brown wrote:
> On Sat, Jul 10, 2004 at 03:44:13AM +0100, Natalia Portillo wrote:
> > Hi.
> >
> > I'm just thinkig...
> > Guessing...
> >
> > Is it possible to emulate a 3Dfx chip?
> > There are available documents, etc?
> >
> > The 3Dfx are the most supported 3D cards.
> > Have drivers for DOS, Windows, MacOS, Linux, BSD, any system where XFree86
> > works, etc.
> >
> > But I think that nVidia has "ghosted" all available information, as they did
> > with the 3Dfx webpage and drivers. :(
I'm uploading the voodoo 3 (avenger) specs to
http://www.scaramanga.co.uk/stuff/voodoo3_spec.pdf (2.9MB) for the
interested.
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re[2]: [Qemu-devel] Re: RFC for new features
2004-07-09 22:13 ` Antony T Curtis
2004-07-10 0:38 ` Derek Fawcus
2004-07-10 2:44 ` [Qemu-devel] 3Dfx... Just guessing Natalia Portillo
@ 2004-07-11 4:45 ` Igor Shmukler
2 siblings, 0 replies; 50+ messages in thread
From: Igor Shmukler @ 2004-07-11 4:45 UTC (permalink / raw)
To: qemu-devel
> > 3) I still think that a virtualizer based on QEMU, while quite a bit more
> > limited in scope than QEMU itself, would be extremely useful : letting
> > user-level code not touching hardware run native and trapping anything
> > related to I/O, memory-mapped I/O or changing protection level (allowing to
> > run *that* on the emulated CPU) would allow for a nice acceleration. This
> > would be a boon for all the people using QEMU to run hardware available for
> > their CPU but not their platform (think Windows user running Linux/FreeBSD
> > software and vice-versa), which may well be a majority among qemu users.
>
> Hmm... If a virtualizer is what is wanted, there are several options
> already available... "Xen" is supposedly very good.
> I think QEmu's strength is that it is not a virtualizer - it is a system
> simulator.
Xen requires modification of guest OS does it not? The problem with that approach (Dynamo) is that one cannot use it to run commercial OSes.
> Perhaps work can be done to get better performance when simulating the a
> similar system to the host... but perhaps there would be more real
> benefit in attemting to make the translator optimise the code it
> generates... LUA has already been mentioned as a possible alternative
> code generator.
What is LUA? Could you please post a link?
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Qemu-devel] (Before) RFC for new features
2004-07-08 18:14 [Qemu-devel] RFC for new features Fabrice Bellard
` (7 preceding siblings ...)
2004-07-09 20:27 ` [Qemu-devel] " Emmanuel Charpentier
@ 2004-07-09 21:51 ` Hetz Ben Hamo
2004-07-09 9:50 ` Johannes Schindelin
8 siblings, 1 reply; 50+ messages in thread
From: Hetz Ben Hamo @ 2004-07-09 21:51 UTC (permalink / raw)
To: qemu-devel
Fabrice Bellard wrote:
> Hi,
>
> As porting the SDL version to other OSes than Linux seems to become an
> important issue, I plan to add the following features in the next days:
I would like to raise an issue which I'm not sure if it was looked closely..
Lets see what do we have today:
* 3 Busses (ISA, ISA PnP, PCI)
* 4 Processors (Pentium Pro, Arm, PPC, Sparc)
* 4 Network cards (NE2000 ISA, AMD PCNet, NE2000 PCI, 3COM PnP ISA)
* 2 Graphics cards (VESA, Cirrus Logic)
* 2 Bioses (PPC BIOS, Generic Bochs/QEMU BIOS)
* 2 hard drive formats (RAW, COW)
And I'm sure I have forgotten few things, not mentioning QEMU is not
that publicallyy published (wait for Slashdot effect)..
I think that something needed here: A plugin mechanism.
What I was thinking that QEMU missing is a way that upon running QEMU
(either first time or doing a first scan), it should "scan" for new
hardware and register them as plugins (with depenedencies, so you cannot
use PPC BIOS with Pentium Pro processor ;) ). That way a new plugin
(either open or closed source) can register itself and a user can simply
use it without having to configure everything..
The method I was thinking was something like Xine player uses when
initializing the player..
Fabrice, others, what do you think about it?
Thanks,
Hetz
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] (Before) RFC for new features
2004-07-09 21:51 ` [Qemu-devel] (Before) " Hetz Ben Hamo
@ 2004-07-09 9:50 ` Johannes Schindelin
2004-07-10 11:49 ` [Qemu-devel] plugins Hetz Ben Hamo
0 siblings, 1 reply; 50+ messages in thread
From: Johannes Schindelin @ 2004-07-09 9:50 UTC (permalink / raw)
To: qemu-devel
Hi,
On Sat, 10 Jul 2004, Hetz Ben Hamo wrote:
> What I was thinking that QEMU missing is a way that upon running QEMU
> (either first time or doing a first scan), it should "scan" for new
> hardware and register them as plugins (with depenedencies, so you cannot
> use PPC BIOS with Pentium Pro processor ;) ). That way a new plugin
> (either open or closed source) can register itself and a user can simply
> use it without having to configure everything..
There is already a plugin system. It requires you to recompile everytime
you add a new piece of hardware, though. I don't think this is a problem
as most likely you will have to recompile anyway to make sure the plugin
uses the same header files as qemu's core.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Qemu-devel] plugins
2004-07-09 9:50 ` Johannes Schindelin
@ 2004-07-10 11:49 ` Hetz Ben Hamo
2004-07-09 13:25 ` Lionel Ulmer
` (2 more replies)
0 siblings, 3 replies; 50+ messages in thread
From: Hetz Ben Hamo @ 2004-07-10 11:49 UTC (permalink / raw)
To: qemu-devel, Johannes.Schindelin
> There is already a plugin system. It requires you to recompile everytime
> you add a new piece of hardware, though. I don't think this is a problem
> as most likely you will have to recompile anyway to make sure the plugin
> uses the same header files as qemu's core.
Yes, but this plugin method is not very usefull for 3rd party plugins..
Many people don't realize one thing about QEMU which differs it from ANY
other emulator: For the first time, you can create a "hardware card",
write drivers for it and test it on guest OS's (Windows, Linux, *BSD,
etc) and test it on other platforms (PPC, Sparc, ARM, once their core is
matured).
Think about it: You can create a new PCI card without buying those all
expensive software to simulate it, write drivers to test it and if it
works well for your customer(s), you can do the real PCI card! Go try
that with VMWare (you can't), BOCHS (good luck hacking their code, and
see the speed difference), and I'm not even mentioning PPC, ARM or Sparc...
With a plugin system (all it takes is 2 files: an text/XML file which
contains the info on this plugin, and a .so file which is the plugin
itself) both closed source and open source developers can add lots of
hardware to QEMU which can be used for driver development on Linux and
on Windows (as well other guest OS's) without having the real hardware.
Have you ever thought to write driver for Linux for some hardware (which
someone can writes a plugin) without having it? now you (potentially) can..
Just my thoughts...
Thanks,
Hetz
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] plugins
2004-07-10 11:49 ` [Qemu-devel] plugins Hetz Ben Hamo
@ 2004-07-09 13:25 ` Lionel Ulmer
2004-07-10 15:23 ` Hetz Ben Hamo
2004-07-09 13:35 ` Bartosz Fabianowski
2004-07-09 13:39 ` Gianni Tedesco
2 siblings, 1 reply; 50+ messages in thread
From: Lionel Ulmer @ 2004-07-09 13:25 UTC (permalink / raw)
To: qemu-devel
> With a plugin system (all it takes is 2 files: an text/XML file which
> contains the info on this plugin, and a .so file which is the plugin
> itself) both closed source and open source developers can add lots of
> hardware to QEMU which can be used for driver development on Linux and
> on Windows (as well other guest OS's) without having the real hardware.
>From what I know, QEMU is GPL'ed (only libqemu is LGPL'ed). So 'closed
source' developers can use this plug-in mechanism ... only if they do not
release their .so :-)
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] plugins
2004-07-09 13:25 ` Lionel Ulmer
@ 2004-07-10 15:23 ` Hetz Ben Hamo
0 siblings, 0 replies; 50+ messages in thread
From: Hetz Ben Hamo @ 2004-07-10 15:23 UTC (permalink / raw)
To: qemu-devel
>>From what I know, QEMU is GPL'ed (only libqemu is LGPL'ed). So 'closed
> source' developers can use this plug-in mechanism ... only if they do not
> release their .so :-)
>
> Lionel
Lionel dear,
I would direct you to a previous project of Fabrice - FFMPEG, which
Fabrice clearly indicated that he would be delight if closed source
project would also use the FFMPEG (Macromedia for example already using
it) and thats why he changed FFMPEG to LGPL license...
So I think that it would be logical from Fabrice to change the hardware
parts license to LGPL or something like that.
Fabrice, whats your opinion?
Thanks,
Hetz
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] plugins
2004-07-10 11:49 ` [Qemu-devel] plugins Hetz Ben Hamo
2004-07-09 13:25 ` Lionel Ulmer
@ 2004-07-09 13:35 ` Bartosz Fabianowski
2004-07-09 13:48 ` Gianni Tedesco
2004-07-09 13:39 ` Gianni Tedesco
2 siblings, 1 reply; 50+ messages in thread
From: Bartosz Fabianowski @ 2004-07-09 13:35 UTC (permalink / raw)
To: qemu-devel
> With a plugin system (all it takes is 2 files: an text/XML file which
> contains the info on this plugin, and a .so file which is the plugin
Binary plugins, especially closed source ones, always create the problem
of binary compatibility. QEMU's 0.5 version number already indicates
that although it works very well already, it is nowhere near finished.
Features change very quickly in CVS, just think about how pci was an
experimental option a short while back and now it's the default. I think
it would be really hard to come up with an API that would remain stable
for multiple releases at this point. Also, the need to maintain
backwards compatibility would hamper QEMU's development. And finally,
creating and maintaining an API would drain lots of resources from QEMU
development while benefiting only very few people who want to distribute
closed source plugins. Maybe at a much later stage, when QEMU is stable
and mature, binary plugins will make sense. But for now, it seems like
the source code extensibility QEMU offers is good enough.
- Bartosz
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] plugins
2004-07-09 13:35 ` Bartosz Fabianowski
@ 2004-07-09 13:48 ` Gianni Tedesco
0 siblings, 0 replies; 50+ messages in thread
From: Gianni Tedesco @ 2004-07-09 13:48 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]
On Fri, 2004-07-09 at 15:35 +0200, Bartosz Fabianowski wrote:
> > With a plugin system (all it takes is 2 files: an text/XML file which
> > contains the info on this plugin, and a .so file which is the plugin
>
> Binary plugins, especially closed source ones, always create the problem
> of binary compatibility. QEMU's 0.5 version number already indicates
> that although it works very well already, it is nowhere near finished.
> Features change very quickly in CVS, just think about how pci was an
> experimental option a short while back and now it's the default.
Adding PCI could easily have been binary backwards compatible. Anyway,
we're not talking about necissarily having a stable or backwards
compatible ABI, just an API which makes developing new code simpler and
makes each module more flexible. It doesn't have to be there to
encourage out-of-tree development at all.
> I think
> it would be really hard to come up with an API that would remain stable
> for multiple releases at this point. Also, the need to maintain
> backwards compatibility would hamper QEMU's development. And finally,
> creating and maintaining an API would drain lots of resources from QEMU
> development while benefiting only very few people who want to distribute
> closed source plugins.
No developing and maintaining a stable or backwards compatible ABI would
do that. An API that doesn't have to be stable or backwards compatible
won't.
> Maybe at a much later stage, when QEMU is stable
> and mature, binary plugins will make sense. But for now, it seems like
> the source code extensibility QEMU offers is good enough.
No, I think plugins should be built from the main qemu source and
external developers would ideally release new plugins as source
distributions to compile against your qemu core. Anything else requires
maintaining an ABI.
Another benefit of DSO based plugins is saving memory and virtual
address space, only loading the plugins which are required. It would
also save on disk space as common code can be shared amongst the various
qemu targets.
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] plugins
2004-07-10 11:49 ` [Qemu-devel] plugins Hetz Ben Hamo
2004-07-09 13:25 ` Lionel Ulmer
2004-07-09 13:35 ` Bartosz Fabianowski
@ 2004-07-09 13:39 ` Gianni Tedesco
2 siblings, 0 replies; 50+ messages in thread
From: Gianni Tedesco @ 2004-07-09 13:39 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]
On Sat, 2004-07-10 at 14:49 +0300, Hetz Ben Hamo wrote:
> With a plugin system (all it takes is 2 files: an text/XML file which
> contains the info on this plugin, and a .so file which is the plugin
> itself) both closed source and open source developers can add lots of
> hardware to QEMU which can be used for driver development on Linux and
> on Windows (as well other guest OS's) without having the real hardware.
2 files? whatever goes in the text/xml file can go inside the DSO just
as easily...
> Have you ever thought to write driver for Linux for some hardware (which
> someone can writes a plugin) without having it? now you (potentially) can..
All I'd like to see changed in the device API is the ability to have a
bit more control over where devices go and make all devices clean to be
used multiple times (ie. like you can have as many NICs as you like).
Then I'd like to see hw/pc.c and hw/ppc.c etc.. go away to be replaced
with 'hardware description files'...
I think that if you wanted to allow the same code to be used by each of
the different CPU emulations, that would be more difficult and could
slow things down at runtime.
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
@ 2004-07-08 19:19 Thomas Munn
2004-07-09 10:02 ` Johannes Schindelin
0 siblings, 1 reply; 50+ messages in thread
From: Thomas Munn @ 2004-07-08 19:19 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
Things I think would be nice:
1. Definately a DISK manager/compressor ala vmware disk images (so I
don't have to waste 4+gb if I don't have a full fileysystem!)
2. Command line support for restoring state files (instead of having
to start and then load state in monitor machines) -state filename?
3. support for -march athlon-xp and -march athlon-xp (and other x-86
processors) for faster binary
Thomas
[-- Attachment #2: HTML --]
[-- Type: text/html, Size: 737 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-08 19:19 [Qemu-devel] RFC for new features Thomas Munn
@ 2004-07-09 10:02 ` Johannes Schindelin
2004-07-09 10:34 ` Julian Seward
0 siblings, 1 reply; 50+ messages in thread
From: Johannes Schindelin @ 2004-07-09 10:02 UTC (permalink / raw)
To: qemu-devel
Hi,
On Thu, 8 Jul 2004, Thomas Munn wrote:
> 1. Definately a DISK manager/compressor ala vmware disk images (so I
> don't have to waste 4+gb if I don't have a full fileysystem!)
Fabrice already mentioned that, right? I would favor using cloop devices,
i.e. using the toolset from cloop to create compressed "devices". Knoppix
uses this system to pack much more than 700MB on a CD.
The advantage of cloop as compared to gzip'ed filesystem: Everytime you
seek in the file, with gzip you have to either have stored a certain zlib
state or decompress the whole file up to that point. With cloop this
problem is solved.
> 2. Command line support for restoring state files (instead of having
> to start and then load state in monitor machines) -state filename?
This is the "-V" option in the VNC patch. For this to work we also need a
save handler for the keyboard. I will prepare that patch later today.
The config file came up a few times. I don't know. For those who
absolutely have to have it, maybe just a file which has exactly the same
syntax as the command line so you don't have to learn two ways to say the
same thing. For sure not an overkill like XML! The extended markup
language is good to markup complex structures, certainly not something as
trivial as a qemu command line.
The Ctrl-Shift-F2 monitor thing is a cute idea, but I really would like to
at least optionally retain the old style monitor.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-09 10:02 ` Johannes Schindelin
@ 2004-07-09 10:34 ` Julian Seward
0 siblings, 0 replies; 50+ messages in thread
From: Julian Seward @ 2004-07-09 10:34 UTC (permalink / raw)
To: qemu-devel
On Friday 09 July 2004 11:02, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 8 Jul 2004, Thomas Munn wrote:
> > 1. Definately a DISK manager/compressor ala vmware disk images (so I
> > don't have to waste 4+gb if I don't have a full fileysystem!)
>
> Fabrice already mentioned that, right? I would favor using cloop devices,
> i.e. using the toolset from cloop to create compressed "devices". Knoppix
> uses this system to pack much more than 700MB on a CD.
>
> The advantage of cloop as compared to gzip'ed filesystem: Everytime you
> seek in the file, with gzip you have to either have stored a certain zlib
> state or decompress the whole file up to that point. With cloop this
> problem is solved.
I don't think it's a good idea to compress the real data in the filesystem
it reduces performance and adds complexity. All that's needed is
to modify the current cow disk system so that unused sectors don't take
any (much) space in the .cow file _without_ having to rely on filesystems
which support holes in files.
vmware (afaik) doesn't really compress disk images, at least not
compression in the gzip/zlib sense. What it does is understand the
filesystem in the disk image, so it knows where the unused sectors are,
and arranges for them to take more or less zero space in the .vmdk
file.
> The Ctrl-Shift-F2 monitor thing is a cute idea, but I really would like to
> at least optionally retain the old style monitor.
I agree it is a good idea. Mostly I just want to run WinXP without
having to have a seperate xterm for the monitor, so I vote in favour
of this one.
J
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
@ 2004-07-08 20:50 Natalia Portillo
2004-07-08 22:48 ` Natalia Portillo
0 siblings, 1 reply; 50+ messages in thread
From: Natalia Portillo @ 2004-07-08 20:50 UTC (permalink / raw)
To: qemu-devel
Support for accessing hardware disks under Win32 (making an ISO of a CD
is difficult).
> -----Mensaje original-----
> De: qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org
> [mailto:qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org]
> En nombre de Fabrice Bellard
> Enviado el: jueves, 08 de julio de 2004 19:14
> Para: qemu-devel@nongnu.org
> Asunto: [Qemu-devel] RFC for new features
>
> Hi,
>
> As porting the SDL version to other OSes than Linux seems to
> become an important issue, I plan to add the following
> features in the next days:
>
> - Virtual console handled by SDL (Ctrl-Shift-F1 to get the
> guest screen,
> Ctrl-Shift-F2 to get the monitor shell, and maybe
> Ctrl-Shift-F3 for various logs).
>
> - Support for more compressed and cow disk images formats so
> that filesystems without hole support can use cow disk images too.
>
> - New tool to create disk images, to compress them and to
> convert between any disk image formats.
>
> - Config file support (syntax: qemu mypc.qmu)
>
> Comments ?
>
> Fabrice.
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [Qemu-devel] RFC for new features
2004-07-08 20:50 Natalia Portillo
@ 2004-07-08 22:48 ` Natalia Portillo
2004-07-09 19:04 ` Jocelyn Mayer
0 siblings, 1 reply; 50+ messages in thread
From: Natalia Portillo @ 2004-07-08 22:48 UTC (permalink / raw)
To: qemu-devel
I forgot to propose:
Select what CPU we want to emulate.
For example under the x86 emulation, what if I want to run a system that
does not work with the current emulated CPU (Pentium Pro) but does with an
older one (for example a 486DX4).
Also in PowerPC emulation, it should be interesting as the 601 has opcodes
that no other 6xx/7xx PowerPC have (that are from POWER).
> -----Mensaje original-----
> De: qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org
> [mailto:qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org]
> En nombre de Natalia Portillo
> Enviado el: jueves, 08 de julio de 2004 21:50
> Para: qemu-devel@nongnu.org
> Asunto: Re: [Qemu-devel] RFC for new features
>
> Support for accessing hardware disks under Win32 (making an
> ISO of a CD is difficult).
>
> > -----Mensaje original-----
> > De: qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org
> > [mailto:qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org]
> > En nombre de Fabrice Bellard
> > Enviado el: jueves, 08 de julio de 2004 19:14
> > Para: qemu-devel@nongnu.org
> > Asunto: [Qemu-devel] RFC for new features
> >
> > Hi,
> >
> > As porting the SDL version to other OSes than Linux seems
> to become an
> > important issue, I plan to add the following features in the next
> > days:
> >
> > - Virtual console handled by SDL (Ctrl-Shift-F1 to get the guest
> > screen,
> > Ctrl-Shift-F2 to get the monitor shell, and maybe
> > Ctrl-Shift-F3 for various logs).
> >
> > - Support for more compressed and cow disk images formats so that
> > filesystems without hole support can use cow disk images too.
> >
> > - New tool to create disk images, to compress them and to convert
> > between any disk image formats.
> >
> > - Config file support (syntax: qemu mypc.qmu)
> >
> > Comments ?
> >
> > Fabrice.
> >
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [Qemu-devel] RFC for new features
2004-07-08 22:48 ` Natalia Portillo
@ 2004-07-09 19:04 ` Jocelyn Mayer
2004-07-09 19:28 ` Natalia Portillo
0 siblings, 1 reply; 50+ messages in thread
From: Jocelyn Mayer @ 2004-07-09 19:04 UTC (permalink / raw)
To: qemu mailing list
On Fri, 2004-07-09 at 00:48, Natalia Portillo wrote:
> I forgot to propose:
>
> Select what CPU we want to emulate.
> For example under the x86 emulation, what if I want to run a system that
> does not work with the current emulated CPU (Pentium Pro) but does with an
> older one (for example a 486DX4).
> Also in PowerPC emulation, it should be interesting as the 601 has opcodes
> that no other 6xx/7xx PowerPC have (that are from POWER).
I agree with this.
I wonder if the best is to choose the CPU (ie 601/603/604/G3/G4 for
PPC...) or to choose a coherent hw entity (PowerMac G3, ...). I think
the first approach is good for ones who want to emulate exotic hardware
configurations but the second is more usable for end-users.
The good approach may be to be able to select all motherboard components
but have some predefined templates that describes well known
motherboards.
--
Jocelyn Mayer <l_indien@magic.fr>
Never organized
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [Qemu-devel] RFC for new features
2004-07-09 19:04 ` Jocelyn Mayer
@ 2004-07-09 19:28 ` Natalia Portillo
0 siblings, 0 replies; 50+ messages in thread
From: Natalia Portillo @ 2004-07-09 19:28 UTC (permalink / raw)
To: qemu-devel
Hi
> > Select what CPU we want to emulate.
> > For example under the x86 emulation, what if I want to run a system
> > that does not work with the current emulated CPU (Pentium Pro) but
> > does with an older one (for example a 486DX4).
> > Also in PowerPC emulation, it should be interesting as the 601 has
> > opcodes that no other 6xx/7xx PowerPC have (that are from POWER).
>
> I agree with this.
>
> I wonder if the best is to choose the CPU (ie 601/603/604/G3/G4 for
> PPC...) or to choose a coherent hw entity (PowerMac G3, ...).
> I think the first approach is good for ones who want to
> emulate exotic hardware configurations but the second is more
> usable for end-users.
What about both?
> The good approach may be to be able to select all motherboard
> components but have some predefined templates that describes
> well known motherboards.
Yeah.
And think that in PowerMacintosh emulation, there can be almost identically
motherboards, but are a different computer (check Gestalt value, and OF one,
both says the computer model).
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [Qemu-devel] (Before) RFC for new features
@ 2004-07-10 2:41 Natalia Portillo
2004-07-10 13:10 ` Fabrice Bellard
0 siblings, 1 reply; 50+ messages in thread
From: Natalia Portillo @ 2004-07-10 2:41 UTC (permalink / raw)
To: qemu-devel
Well I didn't say about using a real commercial modular BIOS, but making the
QEMU BIOS modular as the commercial ones are.
Making the first, will be a HARD task, and, Award/AMI/Phoenix/MrBIOS won't
let us to do that.
Both VMWare and VirtualPC pays for using a commercial BIOS in their
products.
> -----Mensaje original-----
> De: qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org
> [mailto:qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org]
> En nombre de Jim C. Brown
> Enviado el: viernes, 09 de julio de 2004 21:43
> Para: qemu-devel@nongnu.org
> Asunto: Re: [Qemu-devel] (Before) RFC for new features
>
> On Fri, Jul 09, 2004 at 06:57:21PM +0100, Natalia Portillo wrote:
> > About the BIOS question we should have a modular BIOS.
> >
> > Like AWARD, AMI, Phoenix, etc, BIOS, that have support for a great
> > variety of chipsets and CPUs, and are compiled with
> required modules
> > for each motherboard.
> >
>
> A modular BIOS designed for qemu is ok (e.g. VGABios vs Bochs
> BIOS vs some other hand-written BIOS) but supporting a
> commercial BIOS written for actual hardware is another
> matter. This is very difficult as such a BIOS will expect
> different hardware in different places. Not to mention adding
> support for different types of motherboards/ROM chips. Its
> easier to just fix the current qemu BIOS.
>
> P.S.
>
> Someone is working on that iirc.... posted to the list a
> while back. They loaded qemu directly from a bootloader (so
> there was no host OS, only a guest
> OS) and did some hacking so qemu could access the host BIOS
> directly. So it is possible, just very hard.
>
> > > I don't think that the chipset particularly cares what extended
> > > instructions the CPU can execute... However, BIOS support we are
> > > definitely lacking. IIRC, the BIOS we are using doesn't
> do any PCI
> > > setup
> > > - so we rely on some code in pc.c and pci.c to make the
> chipset look
> > > configured and to set up the BARs.
> > >
> > > --
> > > Antony T Curtis <antony.t.curtis@ntlworld.com>
>
> --
> Infinite complexity begets infinite beauty.
> Infinite precision begets infinite perfection.
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] (Before) RFC for new features
2004-07-10 2:41 [Qemu-devel] (Before) " Natalia Portillo
@ 2004-07-10 13:10 ` Fabrice Bellard
2004-07-10 14:03 ` [Qemu-devel] " Fabrice Bellard
0 siblings, 1 reply; 50+ messages in thread
From: Fabrice Bellard @ 2004-07-10 13:10 UTC (permalink / raw)
To: qemu-devel
Natalia Portillo wrote:
> Well I didn't say about using a real commercial modular BIOS, but making the
> QEMU BIOS modular as the commercial ones are.
>
> Making the first, will be a HARD task, and, Award/AMI/Phoenix/MrBIOS won't
> let us to do that.
> Both VMWare and VirtualPC pays for using a commercial BIOS in their
> products.
I don't care about the BIOS as long as it works with the hardware that
QEMU emulates. I am very satisfied with the current Bochs BIOS. The only
missing stuff is PCI init (it is currently done in QEMU), but it is very
easy to add.
Of course if other people want to try other BIOSes, they are free to do
it :-)
Fabrice.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-10 13:10 ` Fabrice Bellard
@ 2004-07-10 14:03 ` Fabrice Bellard
2004-07-10 14:47 ` Antony T Curtis
0 siblings, 1 reply; 50+ messages in thread
From: Fabrice Bellard @ 2004-07-10 14:03 UTC (permalink / raw)
To: qemu-devel
About the new features: none of them will be for the upcoming 0.6.0
release. Maybe for 0.6.1.
Some comments:
- The old console will still be available with a command line option.
- The disk images will support both free sector compression (as cow
images) and "read-only" zlib based block compression, so that the
FreeOSZoo disk images do not need to be decompressed. QEMU itself will
never store compressed blocks as it is more complicated and less useful.
- The disk images will support AES based encryption.
- There will be no plugin system in the near future. Such systems are
mainly useful for closed source project, which QEMU is not. Moreover, as
in ffmpeg, I don't want to bother about binary compatibility and API
stability at this stage of the project.
- The first version of config file will just contain the same as the
command line options. Then someday there will be more options to add new
hardware dynamically and to change some of its properties... but it will
never use XML !
Fabrice.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-10 14:03 ` [Qemu-devel] " Fabrice Bellard
@ 2004-07-10 14:47 ` Antony T Curtis
2004-07-10 14:57 ` Fabrice Bellard
0 siblings, 1 reply; 50+ messages in thread
From: Antony T Curtis @ 2004-07-10 14:47 UTC (permalink / raw)
To: qemu-devel
On Sat, 2004-07-10 at 15:03, Fabrice Bellard wrote:
> About the new features: none of them will be for the upcoming 0.6.0
> release. Maybe for 0.6.1.
>
> Some comments:
>
> - The old console will still be available with a command line option.
Cool,
> - The disk images will support both free sector compression (as cow
> images) and "read-only" zlib based block compression, so that the
> FreeOSZoo disk images do not need to be decompressed. QEMU itself will
> never store compressed blocks as it is more complicated and less useful.
How about lzo compression? It is vary fast for compression and
decompression and doesn't require much memory to operate.
<snip>
--
Antony T Curtis <antony.t.curtis@ntlworld.com>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Qemu-devel] RFC for new features
2004-07-10 14:47 ` Antony T Curtis
@ 2004-07-10 14:57 ` Fabrice Bellard
0 siblings, 0 replies; 50+ messages in thread
From: Fabrice Bellard @ 2004-07-10 14:57 UTC (permalink / raw)
To: qemu-devel
Antony T Curtis wrote:
> On Sat, 2004-07-10 at 15:03, Fabrice Bellard wrote:
>
>>About the new features: none of them will be for the upcoming 0.6.0
>>release. Maybe for 0.6.1.
>>
>>Some comments:
>>
>>- The old console will still be available with a command line option.
>
>
> Cool,
>
>
>>- The disk images will support both free sector compression (as cow
>>images) and "read-only" zlib based block compression, so that the
>>FreeOSZoo disk images do not need to be decompressed. QEMU itself will
>>never store compressed blocks as it is more complicated and less useful.
>
>
> How about lzo compression? It is vary fast for compression and
> decompression and doesn't require much memory to operate.
I just want that downloaded images can be easily used. Compression for
writing is less useful because hard disks are big enough, so it won't be
available in the first implementation. I agree that LZO would be a good
choice for a read/write compression system.
Fabrice.
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2004-07-11 22:44 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-08 18:14 [Qemu-devel] RFC for new features Fabrice Bellard
2004-07-08 18:46 ` [Qemu-devel] " Emmanuel Charpentier
2004-07-08 18:58 ` Antony T Curtis
2004-07-08 19:05 ` Julian Seward
2004-07-08 19:47 ` Jim C. Brown
2004-07-08 18:54 ` [Qemu-devel] " Antony T Curtis
2004-07-08 19:36 ` Jim C. Brown
2004-07-08 20:31 ` Jernej Simončič
2004-07-08 21:04 ` Jim C. Brown
2004-07-08 22:37 ` Jernej Simončič
2004-07-08 22:57 ` Jim C. Brown
2004-07-09 0:15 ` [Qemu-devel] RFC for new features (Console under Windows) Filip Navara
2004-07-08 23:40 ` OT: Re: [Qemu-devel] RFC for new features Antony T Curtis
2004-07-08 19:45 ` Jocelyn Mayer
2004-07-08 19:00 ` Karel Gardas
2004-07-08 21:44 ` vaise
2004-07-08 19:30 ` Jean-Michel POURE
2004-07-08 19:48 ` Brad Watson
2004-07-08 21:37 ` Jan Dittmer
2004-07-08 22:24 ` malc
2004-07-08 19:35 ` Jim C. Brown
2004-07-09 20:27 ` [Qemu-devel] " Emmanuel Charpentier
2004-07-09 22:13 ` Antony T Curtis
2004-07-10 0:38 ` Derek Fawcus
2004-07-10 2:44 ` [Qemu-devel] 3Dfx... Just guessing Natalia Portillo
2004-07-10 13:06 ` Fabrice Bellard
2004-07-10 20:41 ` Natalia Portillo
2004-07-11 21:20 ` Ishwar Rattan
2004-07-11 22:42 ` Natalia Portillo
2004-07-11 1:10 ` Jim C. Brown
2004-07-11 11:16 ` Gianni Tedesco
2004-07-11 4:45 ` Re[2]: [Qemu-devel] Re: RFC for new features Igor Shmukler
2004-07-09 21:51 ` [Qemu-devel] (Before) " Hetz Ben Hamo
2004-07-09 9:50 ` Johannes Schindelin
2004-07-10 11:49 ` [Qemu-devel] plugins Hetz Ben Hamo
2004-07-09 13:25 ` Lionel Ulmer
2004-07-10 15:23 ` Hetz Ben Hamo
2004-07-09 13:35 ` Bartosz Fabianowski
2004-07-09 13:48 ` Gianni Tedesco
2004-07-09 13:39 ` Gianni Tedesco
-- strict thread matches above, loose matches on Subject: below --
2004-07-08 19:19 [Qemu-devel] RFC for new features Thomas Munn
2004-07-09 10:02 ` Johannes Schindelin
2004-07-09 10:34 ` Julian Seward
2004-07-08 20:50 Natalia Portillo
2004-07-08 22:48 ` Natalia Portillo
2004-07-09 19:04 ` Jocelyn Mayer
2004-07-09 19:28 ` Natalia Portillo
2004-07-10 2:41 [Qemu-devel] (Before) " Natalia Portillo
2004-07-10 13:10 ` Fabrice Bellard
2004-07-10 14:03 ` [Qemu-devel] " Fabrice Bellard
2004-07-10 14:47 ` Antony T Curtis
2004-07-10 14:57 ` Fabrice Bellard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).