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

Header file names/directories #36

Open
phil-levis-google opened this issue Dec 27, 2018 · 0 comments
Open

Header file names/directories #36

phil-levis-google opened this issue Dec 27, 2018 · 0 comments

Comments

@phil-levis-google
Copy link

One of the advantages of Tock's supporting processes written in C is that you can take existing C code and (comparatively) easily port it into Tock. This has been fine so far for some simpler chunks of C (like the first RF233 stack). I'm porting a whole U2F application, however, and name collisions are becoming a problem. In particular, the fact that libtock-c defines names like "timer.h", "console.h", and "crc.h" causes name collisions for #include directives which are frustrating to track down (and then change many includes in many files).

Here are three options:

  1. Continue as now and have process writers suck it up. This makes sense if we want to strongly prioritize greenfield process writing over porting, such that the benefits of simpler names to greenfield apps outweigh the costs to ports.
  2. Change all of the tock include files to be tock_, e.g., tock_timer.h. This allows us to keep the current directory structure and include directives.
  3. Change all of the tock include files to be included as #include tock/, e.g., #include tock/timer.h. This allows us to keep the current file names but will require a slightly different directory structure.

The second two options also relate to the syscall names themselves. For example, I'm running into a case when I need to run AES with different modes than what the current Tock syscalls provide. In this particular case, it's not too difficult to avoid conflicts because the AES functions are very descriptively named, but requiring different timer abstractions for 64 bit timestamps is a bit trickier.

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

No branches or pull requests

1 participant