Re[2]: [Qemu-devel] Config file support
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, Paulmailto:[EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re[2]: [Qemu-devel] Config file support
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, Paulmailto:[EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re[2]: [Qemu-devel] Config file support
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.
Re[2]: [Qemu-devel] Config file support
Hello Rob, Wednesday, October 25, 2006, 2:28:47 AM, you wrote: On Monday 23 October 2006 9:38 pm, Paul Sokolovsky wrote: Maybe. But where are new chips in qemu? Why there're still only 2 ARM boards? How do I stick wi-fi card in one of them? So the concern is not just if it's easy to add new devices or not, but if there're means to actually support appearance and growth of device library. Plugin system would be a decree that there's a stable API to define devices and welcome for 3rd-party developers to develop them. Because the lack of a stable internal API has completely prevented Linux from getting any sort of device support. It runs on far less hardware than things like Solaris, with such a stable API... 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? Those Linux guys should really take that GPLv3 pill, don't you think? Yummy! ;-) P.S. This is not a troll People who are not trolling generally don't have to _say_ they aren't trolling. Well, let's face it - that's your comments on *.PIF files and XML parsers that add spice (*1) to the discussion. So don't be surprised that people start to reassure... ;-) Oh, and while we still talking (and to add even more confusion), how'd you guys managed to kill ps ax to work in busybox 1.2.1? I really miss it here, when loading my embedded images into QEMU... Rob *1 flamy -- Best regards, Paulmailto:[EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re[2]: [Qemu-devel] Config file support
Hello Paul, Monday, October 23, 2006, 11:29:52 PM, you wrote: On Monday 23 October 2006 21:01, Rob Landley wrote: On Sunday 22 October 2006 2:27 pm, Paul Brook wrote: I've been considering a machine config file for a while, but haven't come up with a coherent way of representing everything yet. I'm glad this discussion was brought up on the list. And I'd like to also bring back another related issue - what about providing plugin system for device (chip) implementation, in addition to flexible-format machine config allowing to construct virtual boards out of them? Do you at least have a list of everything that needs to be represented? (I have a list but am fairly certain it's not complete.) Not really. I guess a generic key/value pair is sufficient for most things (base address, model number, etc). The trickier cases are where devices refer to each other: PCI, usb, IRQ lines, DMA channels, etc. ie. anything where the existing _init function returns a value. I guess you could use the same key/value mechanism, and allow the value to be an object. Yes, machine config apparently would be a hierarchical structure, with cross-references. And well, there's an industrial standard to represent that - XML. The really OTT method is to embed a python interpreter or something and do the machine init that way. I'm not seriously suggesting that though. Well, I guess, machine configuration really a declarative information, and XML should be enough. But it would be really nice to have Python bindings to implement device plugin, especially for boring hardware like, say, battery controllers. What about config like: qemu devices deviceDef type=builtin name=pxa25x impl=PXA25X / deviceDef type=builtin name=ram impl=RAM / deviceDef type=plugin name=w1ctrlr impl=w1controller.so / deviceDef type=python name=ds2762 impl=ds2762.py / /devices boards board name=pda device name=pxa25x param name=cpuid value=0x / /device device name=ram addr=0xa000 size=32M / device id=w1 name=w1ctrlr addr=0x1000 size=16 irq=67 / device name=ds2762 parent=w1 param name=w1addr value=2 / /device /board /boards /qemu Paul -- Best regards, Paulmailto:[EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
