[openib-general] OpenIB: OS Portablilty?

Wed Apr 7 16:35:38 PDT 2004

Just speaking for myself, not the whole OpenIb project...

    fabbri> 1. There appears to be a goal of separating the openib
    fabbri> stack into OS-dependent and OS-independent parts, where
    fabbri> possible.  However, when I grep'ed the source for
    fabbri> "#include <linux/" I found that almost all subdirectories
    fabbri> in the code tree had code which touches linux source.  The
    fabbri> includes are surrounded by #ifdef's (win2k) in most
    fabbri> cases. However, this means the porting effort is
    fabbri> widespread.

The #ifdefs are really just historical in many places.  This codebase
has never been used under Windows.

    fabbri> 2. The openib codebase is rather large (some 174,000 lines
    fabbri> of code).  To support only the aforementioned protocols,
    fabbri> what can I discard?  For example I know I don't need SRP,
    fabbri> i'm not using SCSI.

If you only want IPoIB and SDP, you can discard the ulp/srp and
ulp/dapl directories (ulp/dapl is a kernel-mode helper for the
userspace uDAPL API).  Also, the core cm (communication manager) and
dm_client (device management client) modules won't be necessary.

    fabbri> As you can see I don't know what a lot of these subdirs
    fabbri> represent.  What code lives in the mpga, provider, hh,
    fabbri> thh, client_query, and core directories?  Are my other
    fabbri> descriptions valid?

provider is the layer of code that interfaces the Mellanox HCA driver
to the core IB code.  client_query provides services for sending MAD
queries and demultiplexing the replies.  core is the main API (and
some deprecated utilities, backwards compat glue, etc).

    fabbri> 5. In the long term, does the openib project aim for OS
    fabbri> independence, or tight coupling with linux?

One major goal of the OpenIB project is integration in the official
Linux kernel tree.  This means that the kernel part of the code needs
to be fully Linux native, without any OS abstraction layer.  However,
I would be delighted to provide help to a native *BSD kernel
InfiniBand stack, and I think the OpenIB project would be willing to
host the source repository etc.  Also, making the userspace side of
things portable to *BSD would be reasonable.

In my opinion, OS-independent device drivers never really work out
very well anyway; forking the code and building a native *BSD stack is
probably the best way to go in the long run.

 - Roland

-- 
To unsubscribe send an email with subject unsubscribe to openib-general at openib.org.
Please contact moderator at openib.org for questions.