Project directory/files structure

[semihalf-berestovskyy-andriy]

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 54

Date: 2015-10-21 11:54:29 +0200
From: Sorin Vultureanu <sorin.vultureanu@enea.com>
To: Sorin Vultureanu <sorin.vultureanu@enea.com>
CC: rasmuss.graaf@enea.com

Last updated: 2015-11-26 12:45:56 +0100

Bugzilla Comment ID: 66

Date: 2015-10-21 11:54:29 +0200
From: Sorin Vultureanu <sorin.vultureanu@enea.com>

Code structure:
The current structure is very flat, e.g. object files are placed in the same directory as c-files. A suggestion here is to mimic the ODP structure.

Bugzilla Comment ID: 67

Date: 2015-10-21 11:57:46 +0200
From: Sorin Vultureanu <sorin.vultureanu@enea.com>

o Lightly modified software e.g. AVL, hash, etc. Would it be beneficial to migrate into a third_party/ directory as a pristine copy where it is easy to maintain and upgrade, then have ‘helpers’ in src/ ?

Bugzilla Comment ID: 85

Date: 2015-10-23 15:51:50 +0200
From: Rasmuss <rasmuss.graaf@enea.com>

Created attachment 1
OFP source file structure proposal

Attached OFP source file strucutre proposal

Attached file: ofp_tree_proposal.txt (text/plain, 2205 bytes)
Description: OFP source file structure proposal

Bugzilla Comment ID: 107

Date: 2015-11-13 14:33:43 +0100
From: Sorin Vultureanu <sorin.vultureanu@enea.com>

Created attachment 2
OFP tree proposal sent on mailing list for review

attached OFP tree proposal sent on mailing list for review

Attached file: ofp_tree_proposal.txt (text/plain, 2134 bytes)
Description: OFP tree proposal sent on mailing list for review

Bugzilla Comment ID: 108

Date: 2015-11-13 18:51:14 +0100
From: Rasmuss <rasmuss.graaf@enea.com>

Hi,

Looks good!

My comments

1. Is there a reason for not having a /net/ folder?
2. Is there a reason why ARP isn't it in /netinet/ folder? (ARP is a IPv4 protocol, IPv6 uses NDP)
3. Where will object files and libraries be placed?
4. Is there a reason why the /api/ folder is placed directly in /ofp/ instead of having a /include/api/, as is the case with ODP?
5. I guess the Makefile is located in /OFp project root/ and the location is a typo.

BR
/Rasmuss

Bugzilla Comment ID: 109

Date: 2015-11-13 18:52:12 +0100
From: Rasmuss <rasmuss.graaf@enea.com>

Hi,

Looks good!

My comments

1. Is there a reason for not having a /net/ folder?
2. Is there a reason why ARP isn't it in /netinet/ folder? (ARP is a IPv4 protocol, IPv6 uses NDP)
3. Where will object files and libraries be placed?
4. Is there a reason why the /api/ folder is placed directly in /ofp/ instead of having a /include/api/, as is the case with ODP?
5. I guess the Makefile is located in /OFp project root/ and the location is a typo.

BR
/Rasmuss

Bugzilla Comment ID: 110

Date: 2015-11-16 12:04:15 +0100
From: Sorin Vultureanu <sorin.vultureanu@enea.com>

Hi,

1. There is no /src/net/ folder as it's functionality was not ported from BSD. There are no files that could go in a /net/ similar to BSD code. Discussed with Bogdan that we need to have some files in /src/ as a place to start. The code that is now in /src/ is the init and core of packet processing that is not BSD like.
2. Same reason as above(non BSD) and the fact that ARP is more related to a /net/ folder than a /netinet/ folder

3. Final deliverable destination can be controlled at build time. Now, temporary object files are in the same directory as .c file, while libraries are in /lib/. We could change to have all object files in /obj/, but ODP also has these temporary objects with the c code. This is a simpler change that can be applied in the configure build files.
4. As all headers are with .c files we don't use an include directory as ODP. We have some debate weather to have this directory named api or include. For me it's clearer with "api" that this directory is for external use rather than internal when use "include". include/api will have an empty include directory and it's taking longer to browse through the code.
5. Yes. Makefile remains where it is now in the root.

BR,
Sorin

Bugzilla Comment ID: 112

Date: 2015-11-17 15:53:58 +0100
From: Rasmuss <rasmuss.graaf@enea.com>

Hi,

OK, one minor comment, with the current layout there will be a mix of files belonging to IPv4 and IPv6 in the /src/ folder, e.g. ofp_ndp.c when it is implemented.

BR
/Rasmuss

Bugzilla Comment ID: 146

Date: 2015-11-26 12:45:42 +0100
From: Sorin Vultureanu <sorin.vultureanu@enea.com>

Created attachment 3
OFP tree proposal REVIEWED on the list with Nokia and ARM

On 11/17/2015 10:41 AM, José Pekkarinen wrote:

Hi,

On Monday 16 November 2015 13:29:21 EXT Sorin. Vultureanu wrote:

Hi Brian, all,

Thank you for the input!
Let's continue to discuss and clarify what should be the agreed solution.

Kind Regards,
Sorin

On 11/13/2015 11:44 PM, Brian Brooks wrote:

On Fri, Nov 13, 2015 at 01:31:03PM +0000, Sorin Vultureanu wrote:

OFP project
│ ├── Makefile
├── config
│ │ └── ofp_config.h
├── api

'include' instead of 'api' ?

Not sure which is the best. Let me explain my reasoning and see which is
better. For me using "api" shows that this directory is for external
interface only. When using "include" someone might not realize that this is
an external API. Leaving "include/api" as we have now, will have an empty
"include" directory and it's taking longer to browse through this
directory. Of course ODP has include directory but headers are in
"include/odp/api" directory.
I don't have any specific preference to this either. As a suggest, we can
start using api as you plan, and we can rethink anything later.

BR.

José.

│ │ └── ofp_.h (all files available now in include/api)
├── src
│ ├── ofp_arp.[c|h]
│ ├── ofp_gre.[c|h]
│ ├── ofp_init*.[c|h]
│ ├── ofp_pkt_processing*.[c|h]
│ ├── ofp_portconf.[c|h]
│ ├── ofp_route*.[c|h]
│ ├── ofp_rt_.[c|h]
│ ├── ofp_vxlan.[c|h]
│ ├── uipc
│ │ ├── ofp_errno.[c|h]
│ │ ├── ofp_hook.[c|h]
│ │ ├── ofp_uipc_.[c|h]
│ │ ├── ofp_sys_socket.[c|h]
│ │ ├── ofp_sysctl.[c|h]
│ │ ├── ofp_syscalls.[c|h]
│ │ ├── ofp_subr_hash.[c|h]
│ ├── linux
│ │ ├── ofp_quagga*.[c|h]
│ │ ├── ofp_netlink*.[c|h]
│ │ ├── ofp_tunthread*.[c|h]

Do we think that all code outside of this 'linux' directory is free of
Linux or platform-specific code & assumptions?

Yes. All code outside of linux/ should be free of Linux. All code outside of
this directory should be ODP-only dependent and some standard C
headers(available in all platforms). The only case where this might not be
100% true is the CLI case, where it creates sockets to Linux stack. But
this code is also divided as a cli/ directory and can be easily
disconnected.

│ ├── netinet
│ │ ├── ofp_icmp*.[c|h]
│ │ ├── ofp_ip_init*.[c|h] ->rename to ofp_ip_input.c
│ │ ├── ofp_in_.[c|h]
│ │ ├── ofp_inet.[c|h]
│ │ ├── ofp_igmp.[c|h]
│ │ ├── ofp_reass*.[c|h]
│ │ ├── ofp_udp_.[c|h]
│ │ ├── ofp_tcp_.[c|h]
│ ├── netinet6
│ │ ├── ofp_udp6*.[c|h]
│ │ ├── ofp_icmp6*.[c|h]
│ │ ├── ofp_in6*.[c|h]
│ │ ├── ofp_ip6_init.[c|h] ->rename to ofp_ip6_input.c
│ │ ├── ofp_nd6.[c|h]
│ ├── utils

'util' instead of 'utils' ?

OK.

│ │ ├── ofp_debug*.[c|h]
│ │ ├── ofp_log*.[c|h]
│ │ ├── ofp_util*.[c|h]
│ │ ├── ofp_timer*.[c|h]
│ │ ├── ofp_stat.[c|h]
│ │ ├── 3rd_party

Generally, third party software is located in the top-level level
directory under third_party/. So,

src/third_party/ instead of src/utils/3rd_party ?

OK.

│ │ │ ├── ofp_avl*.[c|h]
│ │ │ ├── ofp_hash*.[c|h]
│ │ │ ├── ofp_md5c.[c|h]
│ │ ├── cli

src/cli/ instead of src/utils/cli ?

To have less directories in src and to show that it can be disconnected from
OFP it was inside the /util/ directory. Also being in util/ directory shows
this CLI to be a useful functionality. Do we still agree to move it in
/src/ folder ?

│ │ │ └── ofp_cli*.[c|h]

test/ or src/test/ ?

test/ as in ODP ?

---

-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.

---

odp-fp mailing list
odp-fp@lists.enea.com
http://lists.enea.com/mailman/listinfo/odp-fp

Attached file: ofp_tree_proposal_FINAL_REVIEWED.txt (text/plain, 2096 bytes)
Description: OFP tree proposal REVIEWED on the list with Nokia and ARM