qemu-devel
[Top][All Lists]
Advanced

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

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


From: Paul Sokolovsky
Subject: Re[2]: [Qemu-devel] Config file support
Date: Fri, 27 Oct 2006 22:33:11 +0300

Hello Paul,

Wednesday, October 25, 2006, 6:01:48 PM, you 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.
> Kernel size is important because (a) it has to be loaded by the bootloader,
> often from a small, slow device (eg. floppy, flash or network).
> (b) The whole kernel is permanently locked into ram. It you've ever tried to
> build a kernel with everything enable you'll know the result is unreasonably
> large. Modules allow the same kernel to work on a wide variety of large and
> small machines.

  Thanks for your response. But I hope none of us take the discussion
too seriously to consider the arguments like above are all-convincing.
They can be easily reversed by simple replacements of notions. To not
just do s///, how about such questions: when do you think QEMU will
support all (or any, to not sound that naughty ;-) ) of 1K ARM boards
in mach-types will be supported? And if that ever happen, will that
support be in QEMU mainline?


  Well I personally don't care about technical (it's easily doable,
period) or political (they're around all the time - why care too much?)
aspects of that. I'm really more in, so to say, "sociopsychological"
aspects of a product providing dynamically loadable modules/plugins.

  So well, if there was a plugin support with a nice kind of SDK, I
would for sure already hacked emulation for some chip found in
embedded ARM systems (even mock one). But for now, I just wait for
next time I'll be able to setup session to peer into QEMU source.

  What applies to me likely will apply to many more people (it's
*socio*psychological matter). So yes, the question is: do you care
enough to support QEMU-extension community up to the level of making
its life easier? Yes, sure, real men can hack new device support in
QEMU the way it is now. But even real men have constraints on time and
effort involved, so maybe won't have patience to push changes back to
QEMU, and will just leave random snapshots and forks around. And
that's already starting, e.g. http://www.bitmux.org/qemu.html


> It's also a fairly convenient way of allowing userspace to disable a 
> particular set of drivers.

> Closed source kernel modules are explicitly *not* supported by kernel
> developers.

  Cool. They even invented technical scheme to keep non-GPLers away.
You can use that too if you care. Even if you think that someone can
type 3 letters randomly, you can add getLicenceText() call and compare
word-by-word ;-). GPL modules get all features of
register_ioport_read()/register_ioport_write(), non-GPL must call it
with base=0. Fair enough! ;-)

> A typical qemu process already uses well over a hundred Mb of memory. Saving a
> few hundred k of code at runtime isn't going to make any difference to
> anything.

  Yes, as I told, "memory" is not a keyword here. "number of files in QEMU
distribution" and "ease of their maintenance" are.

> Paul


-- 
Best regards,
 Paul                            mailto:address@hidden





reply via email to

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