[openib-general] 2 questions on physical code layout

Mon Oct 25 11:21:24 PDT 2004

On Mon, 2004-10-25 at 13:57, Roland Dreier wrote:
> I have a couple of questions/suggestions about how we want to arrange
> the code for kernel inclusion:
> 
>     1. Does it make sense to remove the ib_ prefixes on .c files in
>        drivers/infiniband/core?  After all, someone looking in
>        drivers/infiniband should realize they're looking at IB source
>        code.  For reference, drivers/usb/core has file with names like
>        hub.c, hcd.c, sysfs.c, ... and net/core has neighbour.c,
>        sock.c, stream.c, ....
> 
>        (If we move our includes somewhere like include/infiniband, I
>        would suggest getting rid of the ib_ prefix from .h files as
>        well, since C files can do "#include <infiniband/verbs.h>")

Seems reasonable to me.

>     2. Should we combine ib_mad.c and ib_agent.c into a single module?
>        In the past I've argued against arbitrarily combining modules,
>        but in this case, ib_agent.c doesn't export any symbols (so
>        dependencies can't bring it in automatically), and everything
>        silently fails if it's not loaded.

Making the agent(s) a separate module was arbitrary and historical. They
can easily be merged. It also seems we could make the MAD module pull in
the agent module if we want to keep them separate.

>        I'm afraid that "Why are my ports stuck in the DOWN state?" is
>        going to become our most popular FAQ if we don't address this.
>        mthca is auto-loaded by hotplug, and modprobe ib_ipoib will
>        bring in every other required module, so ib_agent is the only
>        problem I see right now.
> 
>        I can't think of any situation where one would want IB drivers
>        loaded without a functioning SMI, so I don't see any
>        disadvantage to having ib_agent.c linked into the same .ko as ib_mad.c.

The only situation I can see for this is certain MAD layer tests. 

-- Hal