Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 24 commits into
base: develop
Choose a base branch
from

Conversation

franc0is
Copy link
Contributor

@franc0is franc0is commented Sep 6, 2015

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 franc0is mentioned this pull request Sep 6, 2015
@franc0is
Copy link
Contributor Author

franc0is commented Sep 9, 2015

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
Copy link
Owner

obgm commented Jan 22, 2016

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
Copy link

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
Copy link
Owner

obgm commented Sep 21, 2016

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
Copy link

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
.

mrdeep1 added a commit to mrdeep1/libcoap that referenced this pull request Nov 28, 2022
Fix for later versions of MBed TLS

Fix a couple of ifdef which should be if
mrdeep1 added a commit to mrdeep1/libcoap that referenced this pull request Nov 30, 2022
Fix for later versions of MBed TLS

Fix a couple of ifdef which should be if
mrdeep1 added a commit to mrdeep1/libcoap that referenced this pull request Dec 9, 2022
Fix for later versions of MBed TLS

Fix a couple of ifdef which should be if
mrdeep1 added a commit to mrdeep1/libcoap that referenced this pull request Dec 13, 2022
Fix for later versions of MBed TLS

Fix a couple of ifdef which should be if
mrdeep1 added a commit to mrdeep1/libcoap that referenced this pull request Dec 17, 2022
Fix for later versions of MBed TLS

Fix a couple of ifdef which should be if
mrdeep1 added a commit to mrdeep1/libcoap that referenced this pull request Dec 20, 2022
Fix for later versions of MBed TLS

Fix a couple of ifdef which should be if
mrdeep1 added a commit to mrdeep1/libcoap that referenced this pull request Dec 30, 2022
Fix for later versions of MBed TLS

Fix a couple of ifdef which should be if
mrdeep1 added a commit to mrdeep1/libcoap that referenced this pull request Jan 2, 2023
Fix for later versions of MBed TLS

Fix a couple of ifdef which should be if
mrdeep1 added a commit to mrdeep1/libcoap that referenced this pull request Jan 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants