-
Notifications
You must be signed in to change notification settings - Fork 679
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
Added doxygen documentation for the public API #1
Conversation
* Added module "Application" including vsomeip::application * Added module "Runtime" including vsomeip::runtime Change-Id: If6833a0a7a375576d7bd23f7b69ee74a5bbb28ae
Change-Id: Id25ca6664f8e872714c90e4200788fa23d4d4d1a
Thanks for the contribution! Can I ask that you add a signed-off by line to the request? Thanks! I'll contact the maintainer to see about landing these patches. |
Can you tell me what your signed-off-by policy is? I need to check if I need to do something inside my company before being allowed to add the signed-off-by. |
In a nutshell GENIVI needs to know that you are allowed to make this contribution much like you would if you were contributing to the Linux kernel or other open source projects. In fact our process is pretty much just a copy of the kernel's process. Here is more detail on what we want in the signed-off-by line: https://at.projects.genivi.org/wiki/display/PROJ/How+to+contribute+to+GENIVI#HowtocontributetoGENIVI-PullrequestthroughGithub The company you work for or whomever holds copyright on your contribution won't have to do anything more than provide permission for you to contribute these changes and that permission is evidenced by the signed-off-by line. |
The changes were merged outside this repository. |
When resuming from suspend-to-ram it's likely that UDP SOME-IP works but the TCP socket got broken. Until a new TCP socket gets established, the remote end responds SubscribeNak. The handler will call restart() restart() will early terminate 5 times total. Thereafter it will call shutdown_and_close_socket_unlocked. This is really expensive if the node sends thousands of total requests before a TCP socket gets established. Options include: 1. do not call restart() at all on SubscribeNak. seems safe? 2. fix restart() to early-terminate better in this state, more than 5x 3. ensure that SOMEIP-SD is inhibited in this state (suspend routing?) This commit implements COVESA#1 but the others might be alternatives
AOS-209262 When resuming from suspend-to-ram it's likely that UDP SOME-IP works but the TCP socket got broken. Until a new TCP socket gets established, the remote end responds SubscribeNak. The handler will call restart() restart() will early terminate 5 times total. Thereafter it will call shutdown_and_close_socket_unlocked. This is really expensive if the node sends thousands of total requests before a TCP socket gets established. Options include: 1. do not call restart() at all on SubscribeNak. seems safe? 2. fix restart() to early-terminate better in this state, more than 5x 3. ensure that SOMEIP-SD is inhibited in this state (suspend routing?) This commit implements COVESA#1 but the others might be alternatives
This change adds some initial documentation for the API so that new users get an idea what to call in order to get things working.