Update temperature and humidity to use 2.0 API #178
Conversation
There was a problem hiding this comment.
The logic looks fine, but this seems to inconsistently change things from callback to upcall -- I don't really have strong feelings about which word we use, but currently "callback" is the term used throughout most of libtock-c, if we're going to change names, I think we should do it consistently rather than have a mix of terms (inviting the question: what is the difference between a callback and an upcall?)
|
I think it makes sense to call what happens when a capsule calls I don't think that means we should automatically rename libtock-c, however. The API and terminology presented to userspace applications using libtock-c does not need to be based on the terminology of the kernel. Callbacks in a main.c file look like any other callback in any other language, and renaming them to upcalls is I think unnecessarily adding complexity. Whether they are the direct result of a kernel upcall or come from more software layers in libtock-c (alarms are a good example of this) is not really a concern of an app developer, to them it just looks like a callback. Changing |
|
I think it's good if the libtock-c function names say "callback" rather than "upcall"; as you point out, they might be software-only and so not actually be an upcall. "callback" is the superset so it gives implementation flexibility. But what about the typedef for an argument to subscribe? If we keep it as is, such that applications pass The clean way to do this is for a libtock-c library to filter the upcall into a callback. While the upcall provides 4 arguments, for example, it might be the callback only has 2. So the type you pass to a subscribe is a |
direct function call passed to subscribe. So the internal functions in temperature.c and humidity.c that are passed to subscribe() are called upcalls, but arbitrary function pointers passed from userpsace are called callbacks. This way the API doesn't say whether it's an upcall or not, but the internal implementation knows its own function is so calls it such.
phil-levis
dismissed
ppannuto’s stale review
Changed it back to callback as suggested.
|
bors r+ |
|
Build succeeded: |
177: Tock 2.0 switchover r=hudson-ayers a=phil-levis This PR 1. removes the Tock 1.0 system calls from tock.c, 2. changes `subscribe_cb` to `subscribe_upcall` 3. updates `driver_exists` to use `command2` It **does not** yet change the names (e.g., `command2` to `command`). This because many userspace libraries have not been ported to the new system calls: - [x] tsl2561 @ppannuto #182 - [x] temperature @phil-levis #178 - [x] ~aes~ - [x] ~st7735~ #185 - [x] pca9544a @alevy - [x] lsm303dlhc #191 @alexandruradovici - [x] usb @alistair23 #189 - [x] ~console~ (minor, fixed in this PR) @phil-levis #177 - [x] proximity @alevy #181 - [x] ltc294x @alevy #180 - [x] ~tmp006~ #184 - [x] l3gd20 #192 @alexandruradovici - [x] lps35hb #187 - [x] humidity @phil-levis #178 - [x] max17205 #183 - [x] ipc @alevy #176, #177 This causes an undefined symbol when compiling, so libtock-c is not usable/linkable. But it does compile. As these are fixed, tested, and pushed to `tock-2.0-dev`, I will keep this branch up to date and unblock it when it is ready. Co-authored-by: Philip Levis <pal@cs.stanford.edu> Co-authored-by: Hudson Ayers <hayers@stanford.edu>
177: Tock 2.0 switchover r=hudson-ayers a=phil-levis This PR 1. removes the Tock 1.0 system calls from tock.c, 2. changes `subscribe_cb` to `subscribe_upcall` 3. updates `driver_exists` to use `command2` It **does not** yet change the names (e.g., `command2` to `command`). This because many userspace libraries have not been ported to the new system calls: - [x] tsl2561 @ppannuto #182 - [x] temperature @phil-levis #178 - [x] ~aes~ - [x] ~st7735~ #185 - [x] pca9544a @alevy - [x] lsm303dlhc #191 @alexandruradovici - [x] usb @alistair23 #189 - [x] ~console~ (minor, fixed in this PR) @phil-levis #177 - [x] proximity @alevy #181 - [x] ltc294x @alevy #180 - [x] ~tmp006~ #184 - [x] l3gd20 #192 @alexandruradovici - [x] lps35hb #187 - [x] humidity @phil-levis #178 - [x] max17205 #183 - [x] ipc @alevy #176, #177 This causes an undefined symbol when compiling, so libtock-c is not usable/linkable. But it does compile. As these are fixed, tested, and pushed to `tock-2.0-dev`, I will keep this branch up to date and unblock it when it is ready. Co-authored-by: Philip Levis <pal@cs.stanford.edu> Co-authored-by: Hudson Ayers <hayers@stanford.edu>
178: Update temperature and humidity to use 2.0 API r=phil-levis a=phil-levis In porting over the capsules, somehow the libtock-c parts were missed for temperature and humidity. This updates them to the 2.0 syscall API. Part of tock#177 Co-authored-by: Philip Levis <pal@cs.stanford.edu>
177: Tock 2.0 switchover r=hudson-ayers a=phil-levis This PR 1. removes the Tock 1.0 system calls from tock.c, 2. changes `subscribe_cb` to `subscribe_upcall` 3. updates `driver_exists` to use `command2` It **does not** yet change the names (e.g., `command2` to `command`). This because many userspace libraries have not been ported to the new system calls: - [x] tsl2561 @ppannuto tock#182 - [x] temperature @phil-levis tock#178 - [x] ~aes~ - [x] ~st7735~ tock#185 - [x] pca9544a @alevy - [x] lsm303dlhc tock#191 @alexandruradovici - [x] usb @alistair23 tock#189 - [x] ~console~ (minor, fixed in this PR) @phil-levis tock#177 - [x] proximity @alevy tock#181 - [x] ltc294x @alevy tock#180 - [x] ~tmp006~ tock#184 - [x] l3gd20 tock#192 @alexandruradovici - [x] lps35hb tock#187 - [x] humidity @phil-levis tock#178 - [x] max17205 tock#183 - [x] ipc @alevy tock#176, tock#177 This causes an undefined symbol when compiling, so libtock-c is not usable/linkable. But it does compile. As these are fixed, tested, and pushed to `tock-2.0-dev`, I will keep this branch up to date and unblock it when it is ready. Co-authored-by: Philip Levis <pal@cs.stanford.edu> Co-authored-by: Hudson Ayers <hayers@stanford.edu>
In porting over the capsules, somehow the libtock-c parts were missed for temperature and humidity. This updates them to the 2.0 syscall API. Part of #177