HACKING GNOME KEYRING 

Patches should be submitted to bugzilla:
http://bugzilla.gnome.org/enter_bug.cgi?product=gnome-keyring

Gnome Keyring is made up of several distinct parts working on concert with 
each other. These parts generally live in different directories:

daemon 
   The main daemon startup code and gnome-keyring password protocol operations. 
   
keyrings
   Code that manages the user's password keyrings 
   
library
   The gnome-keyring library for accessing passwords and secrets. 

pk 
   General public key / certificate code, management of objects.

pkcs11
   The PKCS#11 module, provider and headers.

pkix
   Nitty gritty handling of various PKCS#?? standards, parsing, ASN.1 stuff.
      
tests  
   Test tools and unit tests.
   
ui 
   Prompting the user, asking for passwords. 
   

--------------------------------------------------------------------------------
                    USING 'LOCATIONS' INSTEAD OF FILE PATHS

Gnome Keyring supports having keyrings on removable media. Because removable
media can be mounted in different mount-points, and for other related reasons,
what's called a 'location' is used instead of a file point.

Locations are like paths relative to a base. For example certain locations 
might be relative to a home directory, and others might be relative to a USB
drive.

Location functionality:

   common/gkr-location.h
   
Common functions:

   gkr_location_from_path ()
   gkr_location_from_child ()
   gkr_location_to_path ()
   
--------------------------------------------------------------------------------
                            USE OF WORKER THREADS

Gnome Keyring uses threads in a limited manner, as state machines, (ie: execution
stacks). Only one thread runs at any given time, each thread hands off execution
to another thread. 

The *only* use of threading and/or synchronization primitives should be in:
 
   common/gkr-async.c
   
Worker threads are created by using gkr_async_worker_start(). Each worker needs 
to call gkr_async_yield() regularly, to give other threads a chance to run.

If a thread needs perform a blocking syscall, or do something that takes a long 
time (like create a key) it can use the gkr_async_begin_concurrent() and 
gkr_async_end_concurrent() functions. While running 'concurrent' no global
functions and/or data should be accessed.