> However, I wonder since the possible values are defined and fixed, and > not passed directly to vcard_emul_options(), if it shouldn't be an > enum instead. > > Actually, a more future-proof property would be to have a smartcard > emul-options string, don't you think? Hmm. I played with this. I have a patch set for an enum, and an alternate patch set for --spice-smartcard=[vcard_emul_options args] I don't have a clear sense of which one is 'right'. The args would allow us to deprecate the --smartcard-certificates, and --smartcard-db options, and would arguably simplify things. But vcard_emul_options doesn't do any error checking, so a user passing bogus values gets no indication of the problem. They just silently get the default behavior. That could probably be fixed. Also, documenting this starts to feel wonky. It's fairly easy to explain --spice-smartcard=passthru it gets more awkward to explain --spice-smartcard="hw=yes hw_type=passthru" Candidly, I'd appreciate guidance here. I don't have a strong preference, and I'd rather defer to someone who has a strong feeling for what these options should look like. Cheers, Jeremy _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel