Version 2 (modified by 14 years ago) ( diff ) | ,
---|
Where are we now :
Well .. we're in a deep brown smelly thing ...
Jokes aside :
- the app use fork to span processes and use shmem to share data structure between the running processes ... bad , ugly, did I say bad !.. This makes debugging the code difficult.
- There is no unified interface to add modules, reader and other things we might need. The code is all over the place, we don't really know where to change/add things when we want to add support for a new system (reader, crypto, sharing protocol, ...).
- The IO code (csctapi) is a nightmare. The multiple layers :
- reader ->ctapi -> card terminal -> APDU, IO_Serial, SCI, CT_Slot.
- CT_Slot->IFD_Towitoko & ICC -> IO_Serial, SCI
- and a combination of all the above in not particular order or logic !!!
- reader ->ctapi -> card terminal -> APDU, IO_Serial, SCI, CT_Slot.
So it's almost impossible to easily add new reader type in this mess (like PCSC, ..), new module (cccam, ...) or new crypto.
What do we need :
- Move from fork() to threads. This will make debugging with GDB much easier.
- Not use shmem, Once we have thread we need good data structure in memory with mutex for write access (list of reader, list of sharing proto, ...).
- a re-architecture of the IO layer is needed:
- Reader -> IO,Protocol . Each reader need to implement its IO layer (serial, SCI, smartreader+, PCSC, ....). The reader init should only return the ATR. We don't want to auto-switch speed at that point as it depends on the card type.
- Crypto modules. They should have access to the reader to retrieve the ATR, decide whether or not to do au speed change based on the ATR (direct change or via PTS) and use the reader for all their communication with the card.
- Sharing modules : these need to access the crypto module (for local card) or a reader (for remote cards).
All of these module need to be in their own thread and be responsible for updating their data structure (this data structure can be read by other thread based on what they need, only the tread owning the structure can write in it, other thread can send data update to the thread ... this need to be refine and we need to talk about it to find a good way to share the data between the thread without over-engineering the whole thing).
The main thread should only be parsing the config, spawning the threads and monitoring the threads (alert if they die but not quit the whole app, try to re-spawn a thread if it dies).
The logging thread should use a queue instead of the crappy pipes (not working in some case) that we have now (it's probably due to the fork architecture).
I don't think we need to go as far as making all modules and readers as plugins, but we definitely need some common interface to facilitate the integration of new modules and reader.