Re: [Qemu-devel] Config file support

[Paul Brook]

> > 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?

All the boards qemu emulates are supported out the box by mainline linux 
kernels.

>   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.

You seem to be confusing a binary plugin interface with documentation.
The two are independent.  I really don't buy "I would have developed stuff if 
there was a plugin interface" as an argument. If you bothered to look you'd 
find the qemu fairly modular.

>   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

I don't think a binary plugin interface will help with this.
How are abandoned binary plugins better than abandoned open source projects?
At least with the latter interested third parties have the option of picking 
them up and making them work.

> > 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.

Binary plugins don't make things easier to maintain. They just mean you're 
locked in to a particular interface, and can't change anything.

The kernel manages perfectly well with everything in the same tree.

Paul