Il 11/09/2013 16:10, Alex Bligh ha scritto:
>
>
> --On 11 September 2013 13:38:27 +0800 Fam Zheng <f...@redhat.com> wrote:
>
>> + switch (type) {
>> + case MODULE_LOAD_BLOCK:
>> + path = CONFIG_PREFIX "/qemu/block/";
>> + break;
>> + case MODULE_LOAD_UI:
>> + path = CONFIG_PREFIX "/qemu/ui/";
>> + break;
>> + case MODULE_LOAD_NET:
>> + path = CONFIG_PREFIX "/qemu/net/";
>> + break;
>> + default:
>> + return;
>> + }
>> +
>
> I appreciate I am coming in late into this discussion, and am only scanning
> the code quickly, so apologies if I have the wrong end of the stick.
You're absolutely not coming in late! So far we really just discussed
the build side of the implementation, and I didn't review this patch at all.
> This APPEARS to load modules from
> a) a fixed path determined at compile time
> b) a path which is not dependent on qemu version
c) a path that is not under the normal /usr/lib or similar path.
> This would make it hard to have 2 versions of qemu installed on a
> system at once, or even develop one version of qemu with another
> version installed.
This is hard anyway because the firmware files are not necessarily
compatible with different QEMU versions. With 2 versions of QEMU
installed on a system, I would suggest putting both of them in different
subdirectories under /opt.
However, (c) is a problem and...
> I suspect this will be hard not only for developers,
> but also for distributions, particularly if the idea is to keep vms
> running during upgrades. Consider the case where packages A and B
> both depend on qemu module package C, then you wish to upgrade to
> A', B' and C'. At some point you are likely to want both C and C'
> installed. Is the idea here that QEMU is always built with CONFIG_PREFIX
> having versioning inside it (in a distro environment)?
>
> Can I suggest that at the very least, it should be possible to specify
> an alternate path to the module directory via the CLI?
... this is also a good idea. Probably it should use an algorithm
similar to that used for data_dir.
Paolo
