Hello, On Sep 6, 2010, at 3:36 PM, Viktor TARASOV wrote: >> There are five options to deal with the legacy when implementing this >> feature: >> >> a) include pkcs15 specific headers in pkcs11-global.c. Would be a >> "violation" for the rest of those "global" functions as they currently are. >> But could be "right" in the long run, as the PKCS#11 module should be >> enritely built upon PKCS#15 layer of libopensc (be it R/O or initialization >> code) >> b) move C_GetTokenInfo to framework-pkcs15.c. Is a violation for the rest of >> framework-pkcs15.c and maybe insults pkcs15-global.c, but simple. >> c) create a new "global-pkcs15.c" or "pkcs15-token.c" style file with >> C_GetTokenInfo, that talks directly to libopensc, bypassing the "framework" >> glue in the PKCS#11 module, maybe shifting some other "global but >> PKCS#15-ish" stuff there. >> d) extend the "framework-framework" code inside PKCS#15 to define a >> update_token function or something similar? >> e) omit the change because it "does not fit in the file hierarchy" >> f) something else ? >> >> The only other option for me could be a). I chose b). Would a) be better or >> do you have other suggestions? >> > > As for me, firstly the frame-less pkcs11 should be commited and after > that the needed functionality implemented. > Meanwhile (as a rapid answer) extend the 'framework'.
Sorry, that would be like beating a dead badger with a sausage - "fun" but pointless. If you look at the code closely, you see that framework-pkcs15init.c is mostly garbage, with only a single goal of reacting to C_InitToken. Which, I assume, does not work very well anyway. The rest of pkcs15init (one of the two "frameworks") functions return (incorrectly) CKR_CRYPTOKI_NOT_INITIALIZED and framework-pkcs15.c has #ifdef USE_PKCS15_INIT defines that implement calls to pkcs15init functionality, that SHOULD be in framework-pkcs15init.c instead. The "framework framework" is thus an extra, not necessary indirection layer that serves no purpose. In one word: useless. But cleaning it out is more work than implementing one function more-or-less like it should be in the future. The file where it eventually ends up inside src/pkcs11 does not really matter. Once the cleanup is done, it will be clear. -- Martin Paljak @martinpaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
