| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Introduces JSON parser which builds object model of Java API.
Also rewrites JNI translation of typedefs
to use per type translation functions
instead of code inlining.
Not covered:
- integrate with vappigen plugin (VPP-1154) or vapi parser (VPP-1155)
- use better templating engine (VPP-480)
- improvements of generator structure (e.g. VPP-1186)
Change-Id: I9e12d76c2f3c6ee041669f58e8a37917f656aa90
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Change-Id: Iec437e4672af1f0d1a24458afb977ba6fbeba4ed
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
JVpp maps request messages with replies
for Java API user convenience, e.g.:
- do not polute send APIs with messages other than requests/dumps,
- allow callback registration only for replies/details and events.
Since there are no conventions for event message naming
(https://wiki.fd.io/view/VPP/API_Concepts#API_Conventions),
jvpp should not limit events to messages
that end with 'event' or 'counters' suffix.
Instead jvpp should treat all messages
except for requests/dumps as potential events.
Such behaviour was introduced on Java API level by
https://gerrit.fd.io/r/#/c/8377/
in order support reusing
details messages as events (e.g. BFD events).
This patch goes one step forward by
relaxing rules at jvpp generation level.
Change-Id: I2a35e9eb2a288b2cf02d36ca95e6cb13e76e19e3
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Since L2FibTable removal
and introduction of dedicated SW Interface Event,
special message handling code can be removed.
The patch also fixes issues
found by Intelij's code inspection tool.
Change-Id: Ic4b2fd12ac30c7627f4cd6769716e4bb52ec0b10
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
- message sending method inside synchronization blocks causes
deadlock between sending and receiving part
- breaking atomicity of sending message and putting future with
corresponding id to map needs additional handling by writer and receiver,
regardless which part get access to sync block first will create
new future and second one will complete it and remove from map,
in case of dump calls where control ping reply is required
as confirmation that all information were send, if ping reply is
received before writer put future in map, reader will create
regular control ping future instead and writer needs to made association
between these two futures
Change-Id: Id29a19be7a5319291a5e07cf931080610178f00c
Signed-off-by: Matej <matej.perina@pantheon.tech>
|
|
1) In the previous version callbacks were generated based on
request-replay naming conventions. It turned out they were too
strict in case of events (e.g. BFD sends Details messages as
notifications). So now we generate callback for all messages,
allowing to receive any message as notification.(callback_gen.py)
2) "notification" suffix is no longer added because all messages
are treated same (dto_gen.py, jvpp_c_gen_.py)
3) name of property that holds notification/events changed in callback
facade and future apis
4) JVppNotification.java is no longer used since all events are treated
equally
Change-Id: I13f6438affc3473040d63cd4acb3984d03e97482
Signed-off-by: Matej <matej.perina@pantheon.tech>
|
|
Change-Id: I47f9d12d934378f18c6f841b902af2a64ee7b187
Signed-off-by: Matej Perina <mperina@cisco.com>
|
|
Should make Coverity stop thinking we try to synchronize reply.context.
Change-Id: I97169e46b9c8f594836d6beb75b9f42dfc6e5bad
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Change-Id: I1c3b87e886603678368428ae56a6bd3327cbc90d
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
Marek Gradzki
Matej
Matej Perina
Damjan Marion