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? > Certainly, inside the opensc-pkcs11, like in the stomach, all in one place, > but I guess that somebody can be sensible to the order of arrival. > > In this changes the common 'C_' function is defined inside > the 'framework-pkcs15' when 'framework-pkcs15init' is still there. It is still the same way common (or global) as before, as the framework-framework creators did not foresee the need for dynamic token state updates, so this abstraction is missing. > With the same logic we can start to define the common libopensc > functions inside the card drivers. > Why not? At the end of course all this stuff will be inside the same > library. Yes. Many cards do (re-) implement libopensc functions in card drivers. I don't approve it either. But the card driver folder is in a much better shape (and way better defined) than the PKCS#11 implementation, IMHO. > IMHO, first of all the re-design of frameworks has to be done in atomic > manner, > then the upper changes. Sure. I hope it does not make it more complicated to pick out and change the C_* functions. I would suggest deleting the whole framework-framework thing in PKCS#11 and hardwire specific functions to specific libopensc sc_pkcs15_* and sc_pkcs15init_* calls. -- Martin Paljak @martinpaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
