Re[2]: [Qemu-devel] Config file support

[Paul Sokolovsky]

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:address@hidden