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

[Paul Sokolovsky]

Hello Paul,


      Ummm, I must be representing my ideas somewhat unclear... ;-)

Saturday, October 28, 2006, 3:08:20 AM, you wrote:

[]

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

  Well, rereading my passage above I fail to find clause where (for
example) I asked when Linux kernel will support boards QEMU emulates.
Vice versa, I was asking how QEMU makes it possible to *easily*
support any of 1000+ ARM boards currently supported (in some sense of
that word) by Linux kernel.

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

  Oops. Sudden terminology change. Did I ever mention "binary
plugins"? I always talked about "dynamically loadable plugins". Big
difference.

> The two are independent.  I really don't buy "I would have developed stuff if
> there was a plugin interface" as an argument.

  Well, this answers one of my concerns.

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

  Umm, again, I didn't make myself too clear. I'm talking not about
abandoned third party ports, but about active forks of QEMU. As there's
no *well-defined* *source level* API for modules, people prefer to
use entire QEMU source to hack around with adding new device support,
essentially creating a fork. Good that or bad? You decide. I'd say
it's not very productive work pattern, putting additional burden on
those who want to add new devices to QEMU, as well as limiting circle
of potential contributors to QEMU (as general platform for emulation).
(I remember that you don't treat such declarations as ones worth
action; well, that's ok).

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

  Again, no binary API. Just API for *separate, self-contained,
modules*. And once it is there, it will be hard not to implement them
as dynamically loadable. That doesn't mean API is fixed once and forever
(of course no)! It just means that there's some kind of API contract and
care is taken not to be breaking it abruptly. I.e. API changes are planned,
announced, ideally, migration paths are provided, etc. I.e. yes, just
like the Linux Kernel manages it. It "doesn't have stable API", but
see over which deprecation period DEVFS is removed. PCMCIAs are
deprecated and throws dmesg warnings for few releases now, but I heard
it still works even in 2.6.18, etc.

  So yes, if you call that "documentational matter", just please
document that QEMU supports external modules, does that thru
well-defined (in each period of time) API, and care is taken to not
break that API without good need, and even in that case some scheduling
and planning of changes are applied.

  Well, all above may be actually the case already, that's why it may
make you wonder what this stranger wants. But well, in such case, it
is as such for you, a QEMU maintainer. For outsiders, entirety of QEMU
is a monolithic blackbox, anything in which is subject for arbitrary
changes anytime. So just tell us if it's instead a defined system
consisting of black and gray boxes, with the means to add own gray
boxes.

      That's if QEMU is ready for that, of course. And if not, please
consider that for future (actually, just count votes - I keep writing
all this in the hope that someone else might support these ideas).

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

  There're pretty enough drivers/modules outside of the mainline kernel
tree - after all, where had new drivers been before they were accepted
to mainline? And I didn't remember seeing people offering the download
of the drivers as part of the entire kernel snapshot. That's just because
most of drivers work with at least few versions of kernel, and that's
well known and can be relied upon. And rarely outside drivers go as
patches to the kernel - quite often it's a separate small tarball which
doesn't require kernel source at all to be built (just headers ==
SDK), and result can be installed dynamically without disturbing
existing kernel. Why can't that work for QEMU?

> Paul



-- 
Best regards,
 Paul                            mailto:address@hidden