Martin Paljak wrote: > 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. > Sorry, I'm not sufficiently intelligent to perceive your joke. > 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. >
Agree, so, go ahead, get rid of frameworks. Long time ago this task was already mentioned. Finally it's not so complicated, isn't it? > 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. > I've got already know how much time it takes to implement the good intentions in OpenSC. -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
