diff options
author | Tomas Smetana <tsmetana@redhat.com> | 2013-04-24 13:00:54 +0200 |
---|---|---|
committer | Tomas Smetana <tsmetana@redhat.com> | 2013-04-24 13:00:54 +0200 |
commit | 8836aa123cd11df359dfbb7b36da146490dbdfa3 (patch) | |
tree | e2f24b266f8ef87fef097736d4ad5e4ff7e05090 /README | |
parent | e916644d46adf08f49a5bcb1158e4e11120b61cb (diff) | |
download | openlmi-providers-8836aa123cd11df359dfbb7b36da146490dbdfa3.tar.gz openlmi-providers-8836aa123cd11df359dfbb7b36da146490dbdfa3.tar.xz openlmi-providers-8836aa123cd11df359dfbb7b36da146490dbdfa3.zip |
New provider: RealmD
Diffstat (limited to 'README')
-rw-r--r-- | README | 111 |
1 files changed, 110 insertions, 1 deletions
@@ -51,10 +51,15 @@ Following providers are part of this sub-project: Allows to install, remove, list and update packages. Requires python 2.6+ and yum. +* RealmD + This is a CIM interface for the RealmD daemon which allows for the Kerberos + and Active Directory realms enrollment + ******************************************************************************* * Build Dependencies * ******************************************************************************* For all providers: + - cmake - konkretcmpi-devel - sblim-cmpi-devel @@ -71,7 +76,9 @@ Provider specific dependencies: * Service - chkconfig - systemd or upstart or SysVinit - +* RealmD + - glib2-devel + - dbus-devel ******************************************************************************* * Compilation and installation * @@ -87,3 +94,105 @@ $ make You can disable specific provider by adding -DWITH-<PROVIDER>=0 to cmake line. + +******************************************************************************* +* Development Tips * +******************************************************************************* + +Understanding konkret code generation issues: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +konkret is a tool that reads in a mof file and generates C code. For +every XXX class it will generate a XXX.h and XXXProvider.c file. The +code generation occurs due to CMake macros provided by the +openlmi-providers-devel package. konkret needs to run any time you +modify the mof file. It *always* generates a new XXX.h file because +that's where definitions based on the contents of the mof file are +located. If there is no XXXProvider.c file it will also generate +it. This is a "stub" file in which you will fill in with your +implementation. If XXXProvider.c exits it will not overwrite it, +however it always overwrites the XXX.h file. + +Do not put anything into the XXX.h file you'll need to retain. + +After editing the mof file the make targets will cause konkret to run +again. You'll get brand new XXX.h files. But your old XXXProvider.c +files may no longer have the correct definitions (e.g. prototypes) +found in the XXX.h file so you may need to hand edit by copying the +function prototype from the XXX.h file into your XXXProvider.c file. + +If you've written definitions that logically belong in XXX.h but don't +want them nuked the next time konkret runs my solution was to put them +in someother .h file that's included by the XXXProvider.c file. + +Initializing class instances: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The way konkret works is to emit specialized inline functions to +initialize each member of a class. If the class is subclassed you get +different initializers depending on whether the property is in the +parent class or the subclass. You cannot call a parent class property +initializer in a subclass (yuck), you have to use the subclass +initializer for the property inherited from the parent class. This +creates a maintenance problem if the parent class changes, you have +find every place parent class properties are inialized and make +changes. To solve this problem I defined macros that initialize class +properties. The macro takes a "klass" parameter and token pastes it to +generate the class specific property manipulation function call. Using +these macros means anytime a class changes due to a change in the mof +file there is only one place where you need to change the code. These +macros are a good example of what logically belongs in the XXX.h file +but are separated out into a different .h file because konkret will +nuke anything you've added to a XXX.h file. + +Modifications to the provider: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +During development if the mof file changes you have to make Pegasus +reload the mof. It's not sufficient to retart cimserver, you have to +unregister the provider and register it again for Pegasus to see the +mof changes. Thus you would use the openlmi-mof-register command above +except pass the unregister option, followed by the above command, e.g. + +% openlmi-mof-register unregister /usr/share/openlmi-providers/LMI_Realmd.mof /usr/share/openlmi-providers/LMI_Realmd.reg +% openlmi-mof-register register /usr/share/openlmi-providers/LMI_Realmd.mof /usr/share/openlmi-providers/LMI_Realmd.reg + +If all you've done during devopment is modify the provider (not it's +mof definition) then all you need to do is: + +% sudo cimserver -s +% sudo make install +% sudo cimserver + +How do I run the Pegasus CIMOM so I can see debug statements? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +% sudo cimserver daemon=false forceProviderProcesses=false + +How do I use GDB to debug my provider? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Create the following .gdbinit file where XXX is where you want to break. + +<<<<<<<<<< +set breakpoint pending on +b XXX +r daemon=false forceProviderProcesses=false +>>>>>>>>>> + +then run gdb like this: + +% sudo gdb cimserver + +How do I trace what Pegasus is doing? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +% cimserver daemon=false forceProviderProcesses=false logLevel=TRACE traceLevel=5 traceFacility=File traceComponents=All + +The trace file is written to: + +/var/lib/Pegasus/cache/trace/cimserver.trc + +More information about cimserver tracing can be found in the +"OpenPegasus Tracing User Guide" PDF. Google the title to get a +current URL. |