Add debugger support with other platforms

[jimmy-huang]

The current debugger only works on Linux's BSD socket, I am trying to get the debugger to work on Zephyr since it recently added BSD socket support. However, it has slightly different headers for using the socket library and also it currently only supports a subset of the API. It would be nice if we can decouple all those socket APIs like accept(), send(), recv() and sleep() into jerry_port APIs as they can be platform-dependent. Are there any plans to add debugger support for other platforms?

Here's the working here, basically I replaced the debugger-ws.c with my own debugger-ws-zephyr.c when building for Zephyr:
https://github.com/jimmy-huang/jerryscript/tree/js-debugger

[zherczeg]

We also have been thinking about it. TizenRT also needs platform specific changes. Our problem is maintenance: there will be a lot of code duplication.

Anyway this is something we plan to do later in this year.

[martijnthe]

If a lot of code literally has to be duplicated, I think we need to look at factoring out the common parts and coming up with a better interface for providing the "transport" for the debugger communication. I guess that's also what @jimmy-huang is hinting at.

When reworking this, I think we should make it generic enough to also support entirely different types of communications. I'm thinking about USB, UART, BLE, etc.

Where sensible, I think it would also be a good idea to create JerryScript gratified "transport profiles" for each transport where applicable. For example, in the case of USB, it could mean using the same name/class/subclass/endpoints in the USB interface descriptor. That way, the debugger client tooling would only have to have one USB protocol implementation. Note that for the TCP/IP network based transport this "profile" is already there just by virtue of it being designed directly on top of the websocket protocol.

Thoughts?

[zherczeg]

Current requirement is min 64 byte packet with reliable transport, so BLE is probably excluded.

I am neutral about profiles.

[martijnthe]

Current requirement is min 64 byte packet with reliable transport, so BLE is probably excluded.

FWIW, plain GATT (layer immediately below the "application" protocol) allows for MTUs up to 510 bytes GATT payload but not all platforms/stacks support it up to that size. AFAIK, iOS goes up to 155 bytes. Many Android phones do support up to 510 bytes. On top of that, the default is only 20 or so and an MTU exchange needs to happen first, which some BLE device stacks don't support (and even some poor Android devices also don't)...

Anyhow, BLE is probably not the first candidate just because it's more involved than the other ones (USB, UART, ...)

[jimmy-huang]

@martijnthe yes, thanks for pointing that out, even abstracting out the transport layer would be more ideal, I guess the websocket layer does sit in a separate file which kinda does it already, but yeah, a lot of the debugger logic can be shared. As for BLE, another possbility is to use 6lowpan, which is just ethernet, but needs ipv6.

[martijnthe]

@jimmy-huang I left some comments on this commit:
jimmy-huang@85b6e61

[jimmy-huang]

@martijnthe thanks for the feedback, i'll take a look when I get back

[jimmy-huang]

I decided to take a stab to start the work, so I pushed a PR #2247 here with feedbacks from @martijnthe, @zherczeg please take a look, any comments are appreciated.

[zherczeg]

I think this can be closed since we have a generic interface for debugger transport layer now.