-
Notifications
You must be signed in to change notification settings - Fork 683
Debugger Transport APIs and Zephyr port #2247
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
Changes from all commits
364cbdf
00a62a1
3f3da30
567b693
0df2d08
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -38,18 +38,12 @@ typedef struct | |
/** | ||
* Byte data for evaluating expressions and receiving client source. | ||
*/ | ||
typedef struct | ||
typedef struct jerry_debugger_uint8_data_t | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This change seems to be unjustified. Current code base adds names to those structs only that are recursive. Here, it's not the case. |
||
{ | ||
uint32_t uint8_size; /**< total size of the client source */ | ||
uint32_t uint8_offset; /**< current offset in the client source */ | ||
} jerry_debugger_uint8_data_t; | ||
|
||
bool jerry_debugger_accept_connection (void); | ||
void jerry_debugger_close_connection (void); | ||
|
||
bool jerry_debugger_send (size_t data_size); | ||
bool jerry_debugger_receive (jerry_debugger_uint8_data_t **message_data_p); | ||
|
||
void jerry_debugger_compute_sha1 (const uint8_t *input1, size_t input1_len, | ||
const uint8_t *input2, size_t input2_len, | ||
uint8_t output[20]); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -150,6 +150,30 @@ double jerry_port_get_current_time (void); | |
*/ | ||
struct jerry_instance_t *jerry_port_get_current_instance (void); | ||
|
||
/* | ||
* Debugger Port API | ||
*/ | ||
|
||
/* forward declaration */ | ||
struct jerry_debugger_uint8_data_t; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This forward declaration also seems to be unnecessary, especially in this public header. The type is only used in sources internal to jerry-core. If I see it right. |
||
|
||
/** | ||
* Transport APIs, different transport will define | ||
* the real implementation of these APIs | ||
*/ | ||
struct jerry_debugger_transport_t | ||
{ | ||
bool (*accept_connection) (struct jerry_debugger_transport_t *transport_p); | ||
void (*close_connection) (struct jerry_debugger_transport_t *transport_p); | ||
bool (*send) (struct jerry_debugger_transport_t *transport_p, | ||
uint8_t *message_data_p, | ||
size_t data_size); | ||
bool (*receive) (struct jerry_debugger_transport_t *transport_p, | ||
uint8_t *message_data_p, | ||
size_t *data_size, | ||
uint32_t *buffer_offset); | ||
}; | ||
|
||
/** | ||
* Makes the process sleep for a given time. | ||
* | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this port specific definition part of the public API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean the jerry_debugger_transport_t type? Yes, this is intended and part of the jerry_port_ api where each platform have to provide their own definition, hence why it was forward declared, so it can build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately "it can build" is not a strong enough reason for something to be part of the public API.
While I am ok with having a structure for communication, the public API part needs to be independent of everything: no jerry port dependency, no compiler define dependency, etc.
I think the first question is: do we want multiple transport layer support, or the recv/send/close could be provided by jerry port.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zherczeg When I originally started the the port, it was a simpler patch to just port the socket APIs, but I think @martijnthe really like to support multiple transports, so we kinds modified it to take a struct of handlers. I mean we can submit a simpler patch to ports only socket calls and then a separate patch later to rework the APIs to support multiple transports, I think it's up to you and the JerryScript maintainers to make this kind of decision. Honestly, my goal is to at least get the websockets working on Zephyr as part of this effort. If we move the the struct definitions and APIs to from jerryscript-port to jerryscript-debugger.h, would that work for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The definition should NOT be part of the public API, only the forward declaration should be. That way there is no dependency. (Until one actually want to use the debugger feature, in which case one has to pick an implementation which would contain the definition of the struct as well.)
Yes, at least in our project we want to mix and match between 3 transports at run-time.
IMHO, a stronger reason for wanting a more dynamic transport interface as opposed to extending the "port surface" with static functions for the transport, is that static functions would make combining, composing and re-using transport implementations harder.
For example in our case, we want USB, BLE and a "pseudo transport" that just gathers the debug info (i.e. for printing human consumable exception traces). Imagine that someone already wrote each of these transports separately. Each transport would define the same set of functions/symbols. If I want to create a new transport that combines/chains/... them, I'd have to rename each function to avoid conflicts. Even if a simple "switch" between 2 transports would involve renaming each function.