Hi Sanjay. On 07/14/10 05:34 PM, sanjay nadkarni wrote: On 07/14/10 04:39 PM, Evan Layton wrote: Hi Jack, I do still have some concerns with the complexity of be_run_cmd() and how maintainable it will be. However as we discussed I don't have a better suggestion on dealing with the need to capture stdout and stderr separately. One nit related to my maintainability comment above is that it might be helpful to put a comment block (starting at line 3011) that gives a description of how the pollfds stuff works for grabbing both stdout and strerr. As per our phone conversation I'm fine with this updated set of changes. I agree with Evan. The code is way too complicated. It is clear that popen does not do the job that you want, why not simply use fork() and exec and capture the stdout, stderr and stdin from that process. Way too complicated? I've explained why I need to do what I do in other emails... Almost half of the proper code is error handling. Use of fork() and exec() (and dup()) would be even more complicated. In my solution one popen() call and one mkfifo() call do the work of the fork(), exec(), 2 fdopen()s, 2 dup2()s and four close()s. I have the test program to prove it. And I would still have to call poll() to know when to read the pipes, else the deadlock I talked about earlier. So..the caller passes in an array of 3 ints which can be used to pass back. Are the three ints file descriptors for stdin, stdout, stderr? Well, we could fork and exec, and have stdout and stderr go to files -- we don't need stdin right now -- then we would open the files to read them later. However, we agreed at the staff meeting a few weeks ago that writing to a file was hacky and not desired. And that was discussed in the context of using popen where we would only have to write one file for stderr. If the file descriptors went to fifos instead of files, we would have to deal with a two mkfifo() calls (my current solution has only one) and we would still have to use poll() to prevent the deadlocks. So... could it be simpler? Maybe, but mine is definitely not as complicated as it could be. IMHO I still think it is the best solution. Thanks, Jack =Sanjay Thanks, -evan On 7/10/10 5:45 PM, Jack Schwartz wrote: Hi everyone. This webrev supercedes the one I published a week ago, because the situation with SNAP->ON integration has changed. (Thanks to those who reviewed the last one!) It also includes some new changes. Webrev: http://cr.opensolaris.org/~schwartz/100710.1/webrev/ Webrev vs old one (for those who reviewed the last one): http://cr.opensolaris.org/~schwartz/100710.1/webrev.diff/ Please review by Weds 7/14 COB. Changes: - Since we cannot be sure 6944352, which addresses changes we needed for installboot and installgrub, would be done in time to make the ON cutoff for feature freeze, bugs related to that fix have been removed. Added is support for labeled branded zones, and fixes to be_create_menu to return proper errors. - Error message for BE_ERR_UNKNOWN is not "Unknown error" not "Unknown external error" as all external commands are now covered by other errors. - Cleanup of be_create_menu() error handling for 16512 is new. - Addition in libbe.h of "labeled" in BE_ZONE_SUPPORTED_BRANDS for 13865 is new. Note: The new be_run_cmd function in be_utils.c (the bulk of original be_utils.c changes) has not changed. Tested: Labeled zones: - installed trusted solaris and created a zone. Then verified that the zone (and files it had) was properly handled in a new BE. - Ran regression test of libbe test suite from the STC gate and verified that there were no new errors. Messaging of external commands: Hid ict.py, deleted menu.lst and tried to create a new menu to check error output if splash screen could not be added to new menu.lst. Hid installgrub, changed capability file to force installgrub call, and then did beadm activate to check error output when installgrub could not be executed. Modules I changed are lint clean. All files are hg nits clean. Thanks for your time, Jack _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
