Hi Anh, 1) On issue 1, I think it makes perfect sense to name the parameters in the pointer to function type definition signatures. I think it will help to clarify the interface and make it easier to document. I don't think it changes the interface in any material way. 2) On issue 2, here's what I have in the TotalView "mpi_interface.h" file which is the header file for DLL API: /* Update log * ... * Oct 2 2000 JHC: Add the mqs_get_comm_group function to support * partial acquisition. ... */ /* Extract the group from the current communicator. * The debugger already knows comm_size, so can allocate a * suitably sized array for the result. The result is the * rank in COMM_WORLD of the index'th element in the current * communicator. */ extern int mqs_get_comm_group (mqs_process *, int *); We also have the implementation of this function for MPICH1 in a file named "dll_mpich.h", as follows: /*********************************************************************** * Get the group information about the current communicator. */ int mqs_get_comm_group (mqs_process *proc, int *group_members) { mpich_process_info *p_info = (mpich_process_info *)mqs_get_process_info (proc); communicator_t *comm = p_info->current_communicator; if (comm) { group_t * g = comm->group; int i; for (i=0; i<g->entries; i++) group_members[i] = g->local_to_global[i]; return mqs_ok; } else return err_no_current_communicator; } /* mqs_get_comm_group */ We have similar implementations for IBM's MPI DLL on AIX. So, to answer your questions, the functionality is provided by the DLL, and used by the debugger. I don't know why it's not implemented in your MPI or in the current MPICH code. FWIW, TotalView considers the implementation of mqs_get_comm_group to be optional, so if the DLL does not define the function, the TotalView MPI MQD DLL wrapper code returns mqs_no_information. Cheers, John D. Anh Vo wrote:
Hi all,
/_Issue number 1:_/
I�d like to get some feedback on the msq writeup about function definition and their description. Please take a look at 6.8.3, for example
mqs_fetch_data_ft
Function type definition:
typedef int (*mqs_fetch_data_ft) (mqs_process*, mqs_taddr_t, int, void*);
This is how things are defined in the existing interface. Would it actually be more helpful if we do this in the document.
Function type definition
typedef int (*mqs_fetch_data_ft) (mqs_process* pProcess, mqs_taddr_t address, int numBytes, void* buf);
I.e., give each parameter a name, so that it�s easier to explain each of them? Right now my explanation of each of the field is kinda � meh. With each of them having a name, we can probably structure them into IN and OUT fields (similar to the standard).
Note that this will not change the existing interface, just how we present things in the document. The two definitions are completely equivalent as far as the compilers and the code generated are concerned (please shout if this is not true)
Last time on the call everyone kinda insisted that the document should stay as close to the existing interface as possible so I�d like to get an opinion on this.
/_Issue number 2:_/
I don�t see the definition (implementation) of mqs_get_comm_group in our existing code and the existing MPICH code. This should be a functionality provided by the DLL, and not the debugger, am I correct?
--Anh