qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Sokolovsky <pmiscml@gmail.com>
To: Rob Landley <rob@landley.net>
Cc: qemu-devel@nongnu.org
Subject: Re[2]: [Qemu-devel] Config file support
Date: Fri, 27 Oct 2006 23:00:17 +0300	[thread overview]
Message-ID: <821067968.20061027230017@gmail.com> (raw)
In-Reply-To: <200610261031.47226.rob@landley.net>

Hello Rob,

Thursday, October 26, 2006, 5:31:46 PM, you wrote:

> On Wednesday 25 October 2006 11:01 am, Paul Brook wrote:
>> >   Oh, c'mon, Rob! I really didn't want to ask Paul Brook that, but
>> > sure you'll fix my cluelessness right here, right now - tell me, tell me,
>> > why Linux has dynamic-loadable modules support, which clueless passers-by
>> > like me call "plugins"? It must be closed-source diversion, no?
>> 
>> Linux has genuine reasons for wanting modules.

[]

> It also avoids a reboot cycle when you want to debug small changes to drivers
> (assuming you didn't crash).  Restarting a userspace app (like qemu) takes
> five seconds.  Restarting the kernel can take a minute and change, and often
> involves pressing a button on a machine that's shoved under a desk and hard
> to get at.

> I've found avoiding the reboot cycle to be a nice thing with qemu (and User
> Mode Linux), but alas you can't test a driver for hardware qemu doesn't
> emulate.  Nice for filesystems and VM stuff, though...

  Well, I'd like to respond here - not to continue argument, but to
acknowledge that we are not too far away in what we want from QEMU,
even though we (at the first glance) disagree on ways how to achieve
it technically.

  So, yes, alas you can't test a driver for hardware qemu doesn't
emulate. But what if that's just too important to have such
possibility? Don't suspect me of doing something unseemly ;-) - I'm
working on bringing Linux on consumer handheld/PDAs,
http://handhelds.org/wiki . As they are really consumer stuff, i.e. go
without specs, there are always black holes in our implementation
which makes it hard to get usability comparable to closed systems. So,
eventually, to get good support for all chips listed here:
http://handhelds.org/moin/moin.cgi/HandheldHardwareXref (and more
importantly, not listed ;-) ), we'll need to find a way to emulate
them.

  So, there will be a need develop modules for QEMU, and I would like
to be sure that QEMU supports that at all (*supports*, not allows),
and preferably, do it in comfort. So yes, I don't want to hardcode
board/machine config in the code and recompile it each time. After
that it comes idea that I don't want to recompile QEMU even to add new
chip. After that, the idea that I want to prototype chips in
high-level language, not C. (Note that if module/plugin system is
designed right, HL language doesn't have to be supported in QEMU core;
that support as well can be a plugin).


  So yes, all the above is more than a usual QEMU "PC-on-PC" emulation
user wants, but as you see from the above, it stems from the same basic
needs, just aggravated by the fact that embedded hardware is much less
known and supported than "desktop" one.


> Rob



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

  reply	other threads:[~2006-10-27 20:00 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-20 17:55 [Qemu-devel] Config file support Chuck Brazie
2006-10-21  0:12 ` Johannes Schindelin
2006-10-21 10:00   ` Ricardo Almeida
2006-10-21 11:40     ` Stefan Weil
2006-10-22  9:51     ` Johannes Schindelin
2006-10-22 17:01       ` Flavio Visentin
2006-10-22 17:19         ` Martin Guy
2006-10-22 18:27           ` Paul Brook
2006-10-23  6:33             ` [Qemu-devel] " Antti P Miettinen
2006-10-23 20:01             ` [Qemu-devel] " Rob Landley
2006-10-23 20:29               ` Paul Brook
2006-10-23 22:22                 ` Rob Landley
2006-10-23 23:33                   ` Paul Brook
2006-10-24  9:04                     ` Rob Landley
2006-10-24 10:47                     ` Flavio Visentin
2006-10-24 12:05                       ` Christian MICHON
2006-10-24 16:46                         ` Blue Swirl
2006-10-24 20:38                           ` Christian MICHON
2006-10-24 23:32                       ` Rob Landley
2006-10-25  8:20                         ` Johannes Schindelin
2006-10-24  0:11                   ` andrzej zaborowski
2006-10-24  0:34                     ` Paul Brook
2006-10-24  0:12                 ` Re[2]: " Paul Sokolovsky
2006-10-24  0:36                   ` Paul Brook
2006-10-24  1:38                     ` Re[2]: " Paul Sokolovsky
2006-10-24  2:31                       ` Paul Brook
2006-10-24  8:37                         ` Christian MICHON
2006-10-24 23:28                       ` Rob Landley
2006-10-25  0:18                         ` Re[2]: " Paul Sokolovsky
2006-10-25 15:01                           ` Paul Brook
2006-10-26 14:31                             ` Rob Landley
2006-10-27 20:00                               ` Paul Sokolovsky [this message]
2006-10-27 19:33                             ` Re[2]: " Paul Sokolovsky
2006-10-28  0:08                               ` Paul Brook
2006-10-28  1:46                                 ` Re[2]: " Paul Sokolovsky
2006-10-24 23:28                   ` Rob Landley
2006-10-21 18:00   ` David Baird

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=821067968.20061027230017@gmail.com \
    --to=pmiscml@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rob@landley.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).