Martin Paljak wrote: > Hello, > > On Sep 6, 2010, at 11:27 AM, Viktor TARASOV wrote: > >> webmas...@opensc-project.org wrote: >> >>> Modified: trunk/src/pkcs11/framework-pkcs15.c >>> +CK_RV C_GetTokenInfo(CK_SLOT_ID slotID, CK_TOKEN_INFO_PTR pInfo) >>> >>> Modified: trunk/src/pkcs11/pkcs11-global.c >>> -CK_RV C_GetTokenInfo(CK_SLOT_ID slotID, CK_TOKEN_INFO_PTR pInfo) >>> >>> >> I do not agree with this change. >> Why to spoil the old house, when we are not yet ready to build a new one? >> > 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'. -- 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
