Add basic types and functions, initial makefile, and smoke test.

[yosefe]

No description provided.

[shamisp]

@manjugv @fullerdj
Are we going to have other directories than src in the high level ?

I will suggest a bit different layout. Sorry for been picky, but It might be a pain to reorganize it later on. So it is better to get it right from beginning:

High level directories:

tl/ //protocol level
|-->include/
|-->src/

tl/ //transport level
|-->include/
|-->src/

services
|-->include/
|-->src/

So we can build each one as a separate project if we need ?

[yosefe]

IMHO "mopsy" name has to be part of the directory tree, because of include path. you'd install include files in /usr/include/mopsy, which means use them like this: #include <mopsy/...>. that should work during build as well.

[yosefe]

or maybe add "mopsy" subdir to all include/src dirs?

[shamisp]

I thinks the second option (include/mopsy) is the one that is used by libibverbs (http://git.kernel.org/cgit/libs/infiniband/libibverbs.git/tree/).
I don't think you have to use mopsy in "src" dir.

[yosefe]

hmm, that could work. so how about this:
<name>/include/mopsy
<name>/src
proto/include/mopsy
proto/src

<name> can be:

• iface / netif
• chan /channel
• transport / tran / trans / tl

[shamisp]

I like it more.
What about:
cs - communication substrate

[yosefe]

cs - this terminology is not (currently) used anywhere else in the project
i'd like that it would be part of API names, e.g <name>_put_short or mopsy_<name>_put_short

[shamisp]

Then I prefer "tl" (let's keep it short). @uccs/mopsy-maintainer any other comments

[gitrepoidoscar]

I'm assuming that
tl/ //protocol level <== it is 'pl' instead of 'tl'
|-->include/
|-->src/

[shamisp]

It was typo

From: gitrepoidoscar [mailto:[email protected]]
Sent: Thursday, October 23, 2014 1:54 PM
To: uccs/mopsy
Cc: Shamis, Pavel
Subject: Re: [mopsy] Add basic types and functions, initial makefile, and smoke test. (#1)

I'm assuming that
tl/ //protocol level <== it is 'pl' instead of 'tl'
|-->include/
|-->src/

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-60279551.

[manjugv]

My $0.02

I think "src" is kind of redundant. Also, I agree, mopsy should be part of the project.
The high-level directories should differentiate the services provided by the project.
How about this ?

mopsy/API
mopsy/prot
mopsy/tl
services/
examples/
OOB (Connection Manager / CM)/

[yosefe]

i like src because then i don't have something like workdir/mopsy/mopsy

[manjugv]

Your workdir would be "workdir//mopsy". I see that the new name that is being discussed on the email thread will be the highest directory covering all the services.

[shamisp]

Manju wants to say that mopsy in his description is the project name.

I think we need separate directory for each sub-project. As I mention, ideally I would prefer to manage it as a separate projects. Yossi, concerned that this may add to much overhead and this is fine. Nevertheless, we need clear separation on the highest level between different subproject.

So we may have:

/
|-protocols/
| |_include/mopsy/proto.h
| |_src/<component_name>
|
|-transport/
| |_include/mopsy/tl.h
| |_src/<component_name>
|
|-services/
|_include/mopsy/service.h
|_src/<component_name>

[shamisp]

Also we have to add /docs and /contrib to the high level of the project.

[yosefe]

what is contrib for?

[shamisp]

spec files, vim scripts, deb, other stuff usually going there

[shamisp]

Talked with Yossi. We reached agreement on layout:

/
|-proto/
| |_include/mopsy/proto.h
| |_src/
|
|-tl/
| |_include/mopsy/tl.h
| |_src/
|
|-services/
| |_src/
|-docs/ <-- all the documentation will go here
|-contrib/ <-- .vimrc, rpm spec, deb, etc

[yosefe]

i've updated the branch with new code structure

[mike-dubman]

the source files should be under "src/" and not flat in the root.
it is defacto standard and used widely by autotools and other methods.

[yosefe]

we do have src/, but seperately in every sub-project e.g tl/src/

[shamisp]

@miked-mellanox - the idea is to manage these three (pro to, tl, serv) as a separate projects. I think the new layout is good to go.
@yosefe - IMHO it is good to go.

[mike-dubman]

• the problem is that all three sub-projects have common root folder, meaning every shared piece of code will need to go into root folder which will become too big.
• do you plan to build all sub-proj separately or they will be aware of each other and built together with same autotools infra?
• maybe we should keep src/mca/{tl,services,proto} as "plugins" under same root folder which is not "root project folder" ?

[shamisp]

@miked-mellanox

1. Layered design:

-UCH
-UCL
-SERVICES
Service is build first, than UCL, and UCH. So user have an option to install each one separately.

Common code should be in services.

2. Ideally, I wanted to to have each one as a separate project connected through git virtual repository. @yosefe was concerned that it can be too much hassle at beginning.

We should be able to build it separately, why top level script should be able to build the bundle.

3. I think we decided no mca ?

[yosefe]

updated the code.
2) at this point we would like it to be one monolithic project with one build system, but clear separation.
3) yes, at this point no mca