Quoth Gary Mills on Thu, Mar 26, 2009 at 05:52:50PM -0700: > I'm investigating one of the bite-sized bugs, specifically 6383235 for > smf_maintain_instance > and related library functions. It suggests that some of the return codes > from these functions > can be aggregated because they don't make sense to the caller.
The bug is marked as being sponsored by Liane.Praza at sun.com . Have you communicated with her about her status on fixing it? > I've done a review of the return codes from these functions, based on the > code and the man > pages. Although it's not exhaustive, I can see already that in unusual > circumstances they > can return codes that are not documented in their man pages. The caller will > always have > to be written to handle the ones that it can handle, and to issue an error > message for anything > else. Is this the normal situation, or should it be documented in the man > pages? All error codes should be documented. > I can also see the appropriate places to remap the SCF_ERROR_DELETED > return code, although I can't tell how that particular code would be > produced. Is there a test procedure I should be using after I make my code > changes? scf_instance_get_pg() in set_inst_action_inst() could fail with SCF_ERROR_DELETED. To test this, you'd have to have one client delete the instance before another client reached that function, but after successfully finding the instance with scf_handle_decode_fmri() in set_inst_action(). You could write a program which created instances and did this over and over again until it happened, or you might be able to employ DTrace to enlarge the window. > According to the logic of smf_enable_instance(), there may be a few other > return codes > that could be aggregated as well to better fit the ones listed in the man > page. Of course, > many of them may never appear. Is there any point to doing this, or should > we wait for > another bug report? I think the priority for that should be low. If you're interested in doing it, then feel free to proceed. David
