Have tested and it seems Ok. ACK Thanks Lennart
> -----Original Message----- > From: mathi.naic...@oracle.com [mailto:mathi.naic...@oracle.com] > Sent: den 2 maj 2014 23:45 > To: Lennart Lund > Cc: opensaf-devel@lists.sourceforge.net > Subject: [PATCH 0 of 2] Review Request for log: ignore environment variables > when config object exists [#841] > > Summary: log: ignore environment variables when config object exists > [#841] Review request for Trac Ticket(s): #841 Peer Reviewer(s): > lennart.l...@ericsson.com Pull request to: <<LIST THE PERSON WITH PUSH > ACCESS HERE>> Affected branch(es): opensaf-4.3.x, 4.4.x, default > Development branch: <<IF ANY GIVE THE REPO URL>> > > -------------------------------- > Impacted area Impact y/n > -------------------------------- > Docs n > Build system n > RPM/packaging n > Configuration files n > Startup scripts n > SAF services y > OpenSAF services n > Core libraries n > Samples n > Tests n > Other n > > > Comments (indicate scope for each "y" above): > --------------------------------------------- > > changeset 3c0ffef30aadbe886502c9f629af4de39421fa30 > Author: Mathivanan N.P.<mathi.naic...@oracle.com> > Date: Fri, 02 May 2014 17:39:43 -0400 > > log: ignore environment variables when config object exists - part > two > [#841] The OpenSAF integrator can either use the log service > configuration > object or the environment variables to configure the global > configuration > attributes of the log service. By default the configuratino object > logConfig=1,safApp=safLogService is created. This patch detects > whether user > is attempting to configure/use environment variables also when the > configuration object exists. If so, a warning category message is > logged to > the syslog. > > changeset b10c0e26b4f955aef2e5e5223a1d4cec97ea2992 > Author: Mathivanan N.P.<mathi.naic...@oracle.com> > Date: Fri, 02 May 2014 17:40:22 -0400 > > log: fix errno usage for calls to strtoul - part two [#841] On UML based > on > ubuntu, the following code fails consistently. if ((val_str = > getenv(LOGSV_MAX_LOGRECSIZE)) != NULL) { val_uint = > strtoul(val_str, NULL, 0); if ((errno != 0) || (val_uint > > UINT_MAX)) { LOG_ER(Illegal value for > LOGSV_MAX_LOGRECSIZE -....., strerror(errno), > lgsConf->logMaxLogrecsize); > lgsConf->logMaxLogrecsize_noteflag = true; > > i.e. the errno is always getting set to a nonzero value. Because of > this, > when user configures an environment variable, the above code fails > causing > log to assign default values rather than the values from the > environment > variables. As per strotul, errno = 0 has to be done before calling > strotul. > The following NOTE from the man page of strtoul is for reference: > NOTES > Since strtoul() can legitimately return 0 or ULONG_MAX > (ULLONG_MAX for > strtoull()) on both success and failure, the calling program should set > errno to 0 before the call, and then determine if an error occurred by > checking whether errno has a nonzero value after the call. . With this > patch, when a environment variable is configured(when the default > configuration object is not configured) then LOG shall use the value > specified in the environment variable instead of setting default > values. > > > Complete diffstat: > ------------------ > osaf/services/saf/logsv/config/logsv_classes.xml | 5 ++++- > osaf/services/saf/logsv/lgs/lgs_imm.c | 71 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++++++- > 2 files changed, 74 insertions(+), 2 deletions(-) > > > Testing Commands: > ----------------- > 1) Configure environment variable when logConfig=1,safApp=safLogService > is configured. > There should be a warning message in syslog about ignoring the > environment variable. > 2) Configure environment variable when logConfig=1,safApp=safLogService > is not configured. > The values configured in the environment variable shouldbe used for log > service > global configuration attributes. > > Testing, Expected Results: > -------------------------- > Same as above. > > Conditions of Submission: > ------------------------- > Ack from Lennart. > > Arch Built Started Linux distro > ------------------------------------------- > mips n n > mips64 n n > x86 n n > x86_64 y y > powerpc n n > powerpc64 n n > > > Reviewer Checklist: > ------------------- > [Submitters: make sure that your review doesn't trigger any checkmarks!] > > > Your checkin has not passed review because (see checked entries): > > ___ Your RR template is generally incomplete; it has too many blank entries > that need proper data filled in. > > ___ You have failed to nominate the proper persons for review and push. > > ___ Your patches do not have proper short+long header > > ___ You have grammar/spelling in your header that is unacceptable. > > ___ You have exceeded a sensible line length in your > headers/comments/text. > > ___ You have failed to put in a proper Trac Ticket # into your commits. > > ___ You have incorrectly put/left internal data in your comments/files > (i.e. internal bug tracking tool IDs, product names etc) > > ___ You have not given any evidence of testing beyond basic build tests. > Demonstrate some level of runtime or other sanity testing. > > ___ You have ^M present in some of your files. These have to be removed. > > ___ You have needlessly changed whitespace or added whitespace crimes > like trailing spaces, or spaces before tabs. > > ___ You have mixed real technical changes with whitespace and other > cosmetic code cleanup changes. These have to be separate commits. > > ___ You need to refactor your submission into logical chunks; there is > too much content into a single commit. > > ___ You have extraneous garbage in your review (merge commits etc) > > ___ You have giant attachments which should never have been sent; > Instead you should place your content in a public tree to be pulled. > > ___ You have too many commits attached to an e-mail; resend as threaded > commits, or place in a public tree for a pull. > > ___ You have resent this content multiple times without a clear indication > of what has changed between each re-send. > > ___ You have failed to adequately and individually address all of the > comments and change requests that were proposed in the initial review. > > ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc) > > ___ Your computer have a badly configured date and time; confusing the > the threaded patch review. > > ___ Your changes affect IPC mechanism, and you don't present any results > for in-service upgradability test. > > ___ Your changes affect user manual and documentation, your patch series > do not contain the patch that updates the Doxygen manual. ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
