Plugs a memleak in libeis where we don't care about the return value of the
source_add_autoclose().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Motivation for peek is the same as for libei - the upcoming test suite needs
to check a few things before actually dequeuing the event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At least for the test suite, I'll need something that allows me to look at an
event without removing it from the event queue. Just the event type isn't
enough, I need things like "what are the caps on the device". Simplest way to
allow this is a peek function that doesn't remove the event from the queue.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the backend is more of an implementation detail, namespace for
eis_setup_backend_foo()
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The sink dispatch() loop gets the source from the epollfd data pointer, so
unref'ing the source would cause it to be destroyed when we may try to access
it later. Fix the whole source ownership properly, the first ref is owned by
the epollfd and moves to the list of removed sources, the caller gets the
second ref.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The main reason for having different functions to create the initial context
was so we can nest the eis struct inside the context-specific struct. That
shouldn't leak into the API though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For the case where someone else opens the sockets for us - like a test suite
or eventually the portal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're removing it from our own list when returning the event, so increasing
the refcount isn't required.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Refcounting error means we never hit this code, so let's fix it before we fix
the refcounting.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're removing it from our own list when returning the event, so increasing
the refcount isn't required.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the backend is more of an implementation detail, namespace for
ei_setup_backend_foo()
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The main reason for having different functions to create the initial context
was so we can nest the ei struct inside the context-specific struct. That
shouldn't leak into the API though and our use-case is probably one where we
create one context, then iterate through possible backends until one succeds -
having different contexts here doesn't help then.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
That's what copy/pasting does... this argument is the user_data pointer which
we don't care about here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Similar in style to Rust where the unit tests are in the same file. Let's see
how far we can get with that in C. Auto-discovery of tests by forcing the
respective suites into a special test section so we can collect it later from
our unit runner.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
protobuf relies on external framing and exact buffer lengths to parse things
correctly. So let's provide that by sending a fixed-length Frame message
before every real message.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're in a library here, so expecting the caller to handle SIGPIPE just in
case we get it is a bit demanding. Let's use send() instead so we can just
prevent that altogether.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We may get more than one message per dispatch so let's make sure we iterate
through all the available data.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Plain-text was useful for the initial implementation where the counterpart was
netcat but now that both parts are in place, protobuf is a much more
convenient system to handle a frequently-changing protocol.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
buf is the iobuf pointer, we need to check whether we read sizeof(data) bytes
before looping around to fetch more.
And fix the return value for a zero read, because that could either be EAGAIN
or EOF.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The iobuf treats this as binary data but then we're using it as strings in the
message parsing code. So make sure all messages have a trailing null byte.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Better than the current "myclient". Lacks safety and whatnot so long-term it
will have to get replaced with something else.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>