summaryrefslogtreecommitdiffstats
path: root/libglusterfs/src/ctx.c
Commit message (Collapse)AuthorAgeFilesLines
* core: reduce the usage of global variablesAmar Tumballi2012-08-031-4/+2
| | | | | | | | | | | | | | | | | | | | | | | * move all the 'logging' related global variables into ctx * make gf_fop_list a 'const' global array, hence no init(), no edits. * make sure ctx is allocated without any dependancy on memory-accounting infrastructure, so it can be the first one to get allocated * globals_init() should happen with ctx as argument not yet fixed below in this patchset: * anything with 'THIS' related globals * anything related to compat_errno related globals as its one time init'd and not changed later on. * statedump related globals Change-Id: Iab8fc30d4bfdbded6741d66ff1ed670fdc7b7ad2 Signed-off-by: Amar Tumballi <amarts@redhat.com> BUG: 764890 Reviewed-on: http://review.gluster.com/3767 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Anand Avati <avati@redhat.com>
* glusterfs_ctx_t: un-globalize the filesystem contextAnand Avati2012-07-171-0/+47
So far there has been a global glusterfs_ctx_t object which represents the running instance of the filesystem (client or server). It contains the various graphs, connection to the management daemon over which new graphs are obtained, calls stacks issued on this filesystem, and a bunch of such things. With the introduction of libgfapi, it is no more true that there will be only one filesystem context in a process. Applications can be written to use libgfapi and obtain serveral instances of different filesystems/volumes in the same process. This involves messy untangling of assumptions inside libglusterfs that there would only be one global glusterfs_ctx_t and offload that assumption to glusterfsd/ and cli/ (where it is true). Change-Id: Ifd7d1259428c26076140a5764a2dc7361694139c BUG: 839950 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.com/3678 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Amar Tumballi <amarts@redhat.com>