On Wed, 13 Jul 2005, Caitlin Bestler wrote:



-----Original Message-----
From: James Lentini [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 13, 2005 7:48 AM
To: Caitlin Bestler
Cc: openib-general; [EMAIL PROTECTED]
Subject: Re: [openib-general] makiing ibverb.h transport
neutral -- 2nd draft


Why do the transport dependent include files, iwarp_verbs.h
and ibonly_verbs.h, include the generic include file,
rdma_verbs.h? This will require consumer code to be aware of
the different iwarp and ib verbs.

Consumers want to use a generic RDMA interface that hides the
differences between the various transports. Is this proposal
intended to address that requirement?


The transport dependent include file reference rdma_verbs.h
because they are dependent on it. My usual style is to explicitly
include such dependencies and rely on the #ifdefs to filter out
redundant includes.

Most consumer code would only #include rdma_verbs.h. Only those
that needed to perform transport specific conneciton establishment
or error recovery would use the transport specific headers.
Providers, on the other hand, would inlude their transport specific
header file.

Ok, so each file will be (directly) included by a different type of user: rdma_verbs.h by generic RDMA consumers, ibonly_verbs.h (which will become ib_verbs.h) by IB consumers, and iwarp_verbs.h by iwarp consumers.

In that case, why does the rdma_device structure in rdma_verbs.h contain entries for functions with IB specific types (query_gid, modify_device, process_mad, etc.)? Shouldn't these be in the ib specific header?

Keeping knowledge of the IB types in ib_verbs.h would remove the need to define the ib_gid type before including rdma_verbs.h in ib_verbs.h. Include files that require certain symbols to be defined before they can be included can quickly become difficult to maintain.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to