[Pcsclite-muscle] index in PC/SC lite reader names may change

[Martin Paljak]

Hi!

It should not affect anything, indeed. Like macos, where two readers
with the same name (eg vsmartcard) end up with "(1)" and "(2)"
suffixes. In real life, a "stable" reader selection is something
applications do want to have in a multi-reader environment, where
relying on the serial in the name (if available) is an approach I've
used (and matching relevant reader name fragments, not full name).

As pcsc-lite is used mostly on linux/unix machines, this feels like
"eth0" vs "enp0s7" kind of naming aspect. The fact that there can be
non-usb devices in use as qwll makes it impossible to use usb tree
addressing in the name, but what if there could be "many" naming
schemes?

Random brainfart: instead of 0-99 recycle, why not include something
longer but deterministic, like a timestamp or internal event counter ?

BR,
--
Martin
+372 515 6495

On Mon, 11 May 2026 at 17:15, Ludovic Rousseau
<ludovic.rousseau at gmail.com> wrote:
>
> Hello,
>
> I am working on a potential change to pcsc-lite and I would like to
> get your feedback on it.
> What do you think about making the number in the reader name cycle
> instead of always restarting at 0?
>
> Currently, the PC/SC reader names are something like this (for 2
> connected readers):
> "reader A 00 00"
> "reader B 01 00"
>
> The first number is the reader "index".
> The second number is the slot index (for mutti-slot readers)
> See "What is in a PC/SC reader name?"
> https://blog.apdu.fr/posts/2010/05/what-is-in-pcsc-reader-name/ for
> more details.
>
> If "reader A" is unplugged and plugged in again, it will be named
> "reader A 00 00" again.
>
> My proposal is to name the reader "reader A 02 00" instead (or
> whatever the next available number is).
> After 99 readers have been plugged in, we go back to number 00 (if available).
>
> The number in the reader name should NOT be interpreted by the
> application. Therefore, the proposed change should not break existing
> code.
> However, I know that developers can be very creative when using APIs
> and undocumented behaviours :-)
>
> Do you foresee any problems with my proposal?
> Any comments?
>
> Thanks
>
> --
>  Dr. Ludovic Rousseau
>
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle