WIP - split platform-dependent code into per-platform subtrees

[franc0is]

This is a work in progress, and I am only opening the pull request to solicit feedback and share my work before I get too far into it.

I am trying to port libcoap to a variety of platforms, some of which use a as-yet-unsupported IP stack.

The current #ifdef based approach seems unsustainable, I elected to split code into separate platform folders before I did any of the porting work.

I introduced a platform folder which contains platform_[module] files to match the general coap_[module] ones. The file tree looks like this:

platform/
├── contiki
│   ├── platform_address.c
│   ├── platform_io.c
│   ├── platform_io.h
│   ├── platform_time.c
│   └── platform_time.h
├── lwip
│   ├── platform_address.c
│   ├── platform_io.c
│   ├── platform_io.h
│   ├── platform_time.c
│   └── platform_time.h
└── posix
    ├── platform_address.c
    ├── platform_address.h
    ├── platform_io.c
    ├── platform_io.h
    ├── platform_time.c
    └── platform_time.h

The platform is selected using an autoconf variable. The ./configure invocation thus becomes (for example):
$ ./configure PLATFORM=contiki

New ports would only need to provide the platform_[module] files in order to get coap working.

A few things worth noting:

• I have only been testing the POSIX port at the moment. It is likely Contiki et al. do not even compile properly
• This is the first time I've had the chance to work with automake/autoconf. I tried to keep the changes to a minimum and it is likely they could be achieved in a more elegant/robust manner.
• I haven't yet tackled the problem of the abstractions themselves. Ideally, the data structures would become more uniform across platforms.
• libcoap direly needs some sort of continuous integration setup.

TODO:

• Finish splitting up net.h/c and pdu.h/c
• Check Contiki & lwIP builds, make sure they have not regressed (they most likely have :3)
• Write PORTING guide
• Figure out what to do about compiler-specific code (e.g. UNUSED, ...)
• Fall-back to posix in case PLATFORM is not specified
• Cry a lot over the #ifdef WITH_LWIP portions of pdu.c
• Stop crying and abstract away the pbufs

[franc0is]

Progress report:

+ ~/Source/libcoap on fbo* $ grep -R --include=*.c --include=*.h WITH_POSIX .
./include/coap/coap_io.h:#if defined(WITH_POSIX) || defined(WITH_CONTIKI)
./include/coap/coap_io.h:#endif /* WITH_POSIX or WITH_CONTIKI */

[obgm]

I have started to look into this in more detail and would like to pull (most of) it into the development branch. There are some issues to be resolved before that will be possible:

• Rebase to the development HEAD. Recent commits by the package maintainer have introduced whitespace changes that now lead merge conflicts.
• Do not include coap_config.h in header files.
• Avoid platform-dependent include paths in the applications' Makefiles (i.e., get rid of -isystem@top_builddir@/platform/@PLATFORM@/ in example/Makefile.am).
• Use configure --with-platform=... instead of relying on environment variables to specify the target platform.

Moreover, I am not convinced that libev is what we want to use here. I believe that it provides a good and flexible abstraction of the underlying OS primitives and reckon that libcoap will benefit from using it. There is one issue that makes me hesitate accepting this change: libev uses floats to represent times. Although weird, this should not cause trouble on your desktop PC but could lead to more code emitted for (embedded) hardware that does not have a hardware FPU.

[AdrianSoundy]

How is the progress of merging this to the develop branch? I am looking to create a version for the new ESP32 module and it would far easier if it had been restructured.
I can spend some time taking what franc0is has done and moving it to the current develop HEAD, resolving any other issue. Just merging the platform specific stuff and leaving any other changes.

[obgm]

Having received no reaction on my last post that lists what needs to be done before this can be pulled into the develop branch, I consider this work dead. Meanwhile, I have started implementing my own ideas on platform abstraction which is currently part of the dtls branch. I think this is the way to go forward. (At the same time considering the cross-platform fixes of the iotivity folks, of course, see PR #47).

[AdrianSoundy]

I understand the issue you where facing but it seemed so much had already
been done. So you want to base any platform related changes on the dtls
branch. Is there anything i can help with.

On 21 September 2016 at 18:35, obgm [email protected] wrote:

Having received no reaction on my last post that lists what needs to be
done before this can be pulled into the develop branch, I consider this
work dead. Meanwhile, I have started implementing my own ideas on platform
abstraction which is currently part of the dtls branch. I think this is the
way to go forward. (At the same time considering the cross-platform fixes
of the iotivity folks, of course, see PR #47
#47).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#6 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AVOFyfXkELUOIfNudodAemEIavqQmK5pks5qsNAigaJpZM4F4hTO
.