[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 3/7] ccid: build smartcard as module
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH v4 3/7] ccid: build smartcard as module |
Date: |
Tue, 30 Jun 2020 11:44:40 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
On 6/23/20 7:12 PM, Gerd Hoffmann wrote:
> Hi,
>
>>> + { .type = "ccid-card-passthru", .mod = "usb-smartcard" },
>>> + { .type = "ccid-card-emulated", .mod = "usb-smartcard" },
>>
>> We want to use type definitions here (such TYPE_CCID_PASSTHRU),
>> as we don't guaranty them stable.
>
> Hmm? I'm pretty sure '-device ccid-card-passthru' *is* stable ABI.
Asking on IRC, there is no explicit contract.
But as you remarked, doing so would break the CLI, so we should
some day clarify that objects implementing TYPE_USER_CREATABLE
can not have their typename changed. For the rest, there is no
restriction.
>> Since there is a relation between QOM type and the module,
>> can we store/use the module name in the TypeInfo declaration?
>>
>> static const TypeInfo passthru_card_info = {
>> .name = TYPE_CCID_PASSTHRU,
>> .parent = TYPE_CCID_CARD,
>> .instance_size = sizeof(PassthruState),
>> .class_init = passthru_class_initfn,
>> .module_name = "usb-smartcard", <=====
>> };
>
> That doesn't buy us much, the TypeInfo ends up in the module not qemu.
> So qemu can't access it without loading the module.
>
> We do *not* want load all modules on startup though. Which means we
> need a such list in qemu. The struct above is just that. There
> certainly is room for improvement, building that list automatically
> somehow for example.
OK.
> Given that most devices don't depend on external shared libraries I
> expect the list of device modules will stay relatively short. So I've
> decided to start with something simple and see how it goes (see also
> patch 1/7).
>
>> Actually this modularization is not specific to QDEV
>> and can be used to all QOM right? I.e:
>>
>> static const TypeInfo qcrypto_tls_creds_x509_info = {
>> .parent = TYPE_QCRYPTO_TLS_CREDS,
>> .name = TYPE_QCRYPTO_TLS_CREDS_X509,
>> .module_name = "gnu-tls",
>> ...
>> }
>
> Not as-is. You'll need module load hooks in more places then and some
> code tweaks to move it from qdev level (loading hw-* module only) to qom
> level.
>
> But, yes, moving the infrastructure to some qom-module.c file might be
> useful when modularizing non-device objects. Do you have any candidates
> in mind?
So far I was only thinking of gnutls.
- [PATCH v4 1/7] qdev: add support for device module loading, (continued)
- [PATCH v4 1/7] qdev: add support for device module loading, Gerd Hoffmann, 2020/06/22
- [PATCH v4 2/7] build: fix device module builds, Gerd Hoffmann, 2020/06/22
- [PATCH v4 5/7] vga: build qxl as module, Gerd Hoffmann, 2020/06/22
- [PATCH v4 4/7] usb: build usb-redir as module, Gerd Hoffmann, 2020/06/22
- [PATCH v4 6/7] vga: build virtio-gpu only once, Gerd Hoffmann, 2020/06/22
- [PATCH v4 7/7] vga: build virtio-gpu as module, Gerd Hoffmann, 2020/06/22
- [PATCH v4 3/7] ccid: build smartcard as module, Gerd Hoffmann, 2020/06/22
Re: [PATCH v4 0/7] build some devices as modules., Stefan Hajnoczi, 2020/06/23