<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45">
<TITLE>RE: [openib-general] RE: OpenSM Work</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Hi Hal,</FONT>
</P>
<P><FONT SIZE=2>Regarding the directory structure of OpenSM:</FONT>
<BR><FONT SIZE=2>From the developer standpoint it makes life easier to have the H files located on the same directory the C file is located. I still use "grep" a lot.</FONT></P>
<P><FONT SIZE=2>I could not find even one GNU stile project that uses a separate include directory for H files during the development phase (all of them eventually install H files into $prefix/include).</FONT></P>
<P><FONT SIZE=2>Please see the short list of projects below as a reference but actually I picked them randomly from the FSF GNU projects page. </FONT></P>
<P><FONT SIZE=2>Tcl </FONT>
<BR><FONT SIZE=2>Expat</FONT>
<BR><FONT SIZE=2>Enscript</FONT>
<BR><FONT SIZE=2>Gimp</FONT>
</P>
<P><FONT SIZE=2>So I guess this methodology of keeping all H files in a separate directory is more a "kernel" convention?</FONT>
<BR><FONT SIZE=2>What are the implications of moving the H files each into its sources dir?</FONT>
</P>
<P><FONT SIZE=2>This issue is more a style and adherence to the standard coding practices for user level code then something that prevents us from progressing. However I wonder what are the strong reasons for keeping it the way it is?</FONT></P>
<P><FONT SIZE=2>EZ</FONT>
<BR><FONT SIZE=2>Eitan Zahavi</FONT>
<BR><FONT SIZE=2>Design Technology Director</FONT>
<BR><FONT SIZE=2>Mellanox Technologies LTD</FONT>
<BR><FONT SIZE=2>Tel:+972-4-9097208</FONT>
<BR><FONT SIZE=2>Fax:+972-4-9593245</FONT>
<BR><FONT SIZE=2>P.O. Box 586 Yokneam 20692 ISRAEL</FONT>
</P>
<BR>
<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Hal Rosenstock [<A HREF="mailto:halr@voltaire.com">mailto:halr@voltaire.com</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Friday, August 05, 2005 7:24 PM</FONT>
<BR><FONT SIZE=2>> To: Eitan Zahavi</FONT>
<BR><FONT SIZE=2>> Cc: 'Matt Leininger'; openib-general@openib.org</FONT>
<BR><FONT SIZE=2>> Subject: RE: [openib-general] RE: OpenSM Work</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Hi Eitan,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> While I don't understand why the update for 1.8.0 can't be done by</FONT>
<BR><FONT SIZE=2>> patches which is the usual way (I think it could be broken at least into</FONT>
<BR><FONT SIZE=2>> complib, then vendor lib, then SM, and finally SA changes), I will work</FONT>
<BR><FONT SIZE=2>> on merging Yael's branch for this. Note that there may be some back and</FONT>
<BR><FONT SIZE=2>> forth on this similar to comments on patches. In the future, I hope that</FONT>
<BR><FONT SIZE=2>> work can be done in smaller incremental pieces and with patches.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> As to the directory structure, there are projects which follow the</FONT>
<BR><FONT SIZE=2>> structure which is being used in the OpenIB tree. The makefiles already</FONT>
<BR><FONT SIZE=2>> do install the headers. That being said the directory structure is not</FONT>
<BR><FONT SIZE=2>> cast in stone but there is a lot of churn here to change it. Are there</FONT>
<BR><FONT SIZE=2>> any other clear benefits ? Does it somehow make your internal</FONT>
<BR><FONT SIZE=2>> development easier ? If that is it, I don't see why a correspondence</FONT>
<BR><FONT SIZE=2>> script wouldn't work. Typically things like this are community decided.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I would think the simulator work is separable and would prefer to hold</FONT>
<BR><FONT SIZE=2>> off on this until the OpenSM merge is done and working. That alone seems</FONT>
<BR><FONT SIZE=2>> like a lot to swallow at once.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Finally, as to feedback on the proposals for OpenSM work, as I recall,</FONT>
<BR><FONT SIZE=2>> there were responses from both Tom and myself both being supportive of</FONT>
<BR><FONT SIZE=2>> new functionality and some design review issues (particularly relating</FONT>
<BR><FONT SIZE=2>> to routing algorithms proposed). I would expect this work to generate</FONT>
<BR><FONT SIZE=2>> more feedback as there is code to go along with it or possibly even with</FONT>
<BR><FONT SIZE=2>> an update on the design approach.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -- Hal</FONT>
</P>
</BODY>
</HTML>