p11-kit.git - Clone of https://github.com/p11-glue/p11-kit

	Commit message (Collapse)	Author	Age	Files	Lines
*	Move debug and library code into the common/ subdirectory	Stef Walter	2013-01-09	1	-898/+0
\| \| \| \| \| \| \| \| \| \| \|	Start using p11_ as our internal prefix rather than _p11_. We explicitly export p11_kit_ so this is fine as far as visibility. Move the threading, mutex, and module compat, dict, and array code into the common directory too. Take this opportunity to clean up a bit of internal API as well, since so many lines are being touched internally.
*	Initialize mutexes correctly in mock module	Stef Walter	2012-07-26	1	-1/+5
\| \| \| \|	https://bugzilla.gnome.org/show_bug.cgi?id=44740
*	Move the compat.[ch] headers into common directory/	Stef Walter	2012-04-30	1	-1/+1
\| \| \| \| \|	* And the compat stuff in the p11-kit directory merged into util.c and util.h
*	Rename non-static functions to have a _p11_xxx prefix.	Stef Walter	2011-10-24	1	-5/+5
\| \| \| \| \| \| \|	* Work around issues with brain-dead linkers not respecting the libtool -export-symbol-regex argument https://bugs.freedesktop.org/show_bug.cgi?id=42020
*	Initial port to win32	Stef Walter	2011-10-17	1	-6/+14
\| \| \| \| \| \| \| \|	* Tests do not all yet pass, at least not on wine * Added abstraction of some non-portable functions in compat.h/c * Build with an argument like this for win32 support: ./autogen.sh --host=i586-mingw32msvc * This win32 port needs more work from interested parties
*	Only call C_Initialize and C_Finalize once per module	Stef Walter	2011-10-10	1	-2/+2
\| \| \| \| \| \| \| \|	* Do not concurretnly call C_Initialize or C_Finalize in a module * The PKCS#11 spec indicates that mone thread should call those functions. * It's reasonable for a module to expect to only be initialized or finalized in one thread. * In particular NSS does not lock its C_Initialize or C_Finalize.
*	Fix endless loop if module forks during initialization.	Stef Walter	2011-08-14	1	-0/+886
	* If a module forks during its C_Initialize, previously our fork handler would try to initialize it again, ad nauseum. Reported by Nikos on the mailing list.