Hi,
On Wed, Oct 19, 2016 at 1:10 PM, Florian Larysch wrote:
> Currently, libubox uses json_object_get_int when converting a JSON
> document into a blobmsg. However, json-c stores integers as int64_t
> values and may clamp the value when asked to return it as an int32_t.
>
> Always use json_object
Recent glibc warns if result of read() or write() is unused.
Added a retry in case of EINTR, all other faults are silently discarded.
Signed-off-by: Eyal Birger
-
- I was not able to reproduce the EINTR case, but it seems to be the right
thing to do
- Retrying on EAGAIN in this case
On Sat, Jun 4, 2016 at 6:27 PM, Matthias Schiffer
wrote:
> On 06/03/2016 04:55 PM, Eyal Birger wrote:
>>
>> Hi,
>>
>>> On 3 Jun 2016, at 13:11, Matthias Schiffer
>>> wrote:
>>>
>> (snip)
>>>
>>> 1) and 2) would allow blob
Hi Hans,
On Mon, Jun 6, 2016 at 1:03 PM, Hans Dedecker wrote:
> As device name is used as key in avl list a device name change will break the
> avl find logic.
> Function device_set_ifname offers api to set the device name and re-inserts
> the avl node in the list
> when the avl key value is ch
Hi,
> On 3 Jun 2016, at 13:11, Matthias Schiffer
> wrote:
>
(snip)
>
> 1) and 2) would allow blobmsg to store everything that json-c can (with the
> caveat that json-c stores integers as int64 internally, while blobmsg_json
> uses int32) -
We also noticed this as a problem for us since when
When the IP_MULTICAST_LOOP/IPV6_MULTICAST_LOOP socket options are not enabled,
locally generated queries are ignored by mdnsd; This prevents local
applications from being able to discover locally published services.
Signed-off-by: Eyal Birger
---
interface.c | 8
1 file changed, 4
.
Signed-off-by: Eyal Birger
---
libubus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libubus.c b/libubus.c
index d52faff..8163ff7 100644
--- a/libubus.c
+++ b/libubus.c
@@ -294,6 +294,7 @@ int ubus_connect_ctx(struct ubus_context *ctx, const char
*path)
avl_init(&ctx->
On Sun, Apr 24, 2016 at 8:35 PM, Hauke Mehrtens wrote:
> On 04/24/2016 01:47 PM, Eyal Birger wrote:
>> Hi All,
>>
>> We've encountered an interesting behavior in the OpenWRT build system, on
>> which
>> feedback would be appreciated:
>>
>> When b
Hi All,
We've encountered an interesting behavior in the OpenWRT build system, on which
feedback would be appreciated:
When building packages sharing the same source code, all packages
prerequisites seem to
be joined unconditionally, instead of each prerequisite depending on
the package that requ
Hi,
On Tue, Feb 16, 2016 at 12:21 PM Felix Fietkau wrote:
> On 2016-02-16 11:13, Eyal Birger wrote:
> > Hi Felix, thanks for your patience.
> >
> > On Tue, Feb 16, 2016 at 12:00 PM Felix Fietkau > <mailto:n...@openwrt.org>> wrote:
> >
> &g
Hi Felix, thanks for your patience.
On Tue, Feb 16, 2016 at 12:00 PM Felix Fietkau wrote:
> On 2016-02-16 10:06, Eyal Birger wrote:
> > Hi Felix,
> >
> > Thanks again for your responses.
> >
> > On Mon, Feb 15, 2016 at 2:14 PM Felix Fietkau > <mailto:n
Hi Felix,
Thanks again for your responses.
On Mon, Feb 15, 2016 at 2:14 PM Felix Fietkau wrote:
> On 2016-02-15 12:54, Eyal Birger wrote:
> > > > if (offset < sizeof(ub->hdr)) {
> > > > - iov[0].iov_ba
Hi Felix,
Thanks for the quick reply! (sorry for the previous top post...)
On Mon, Feb 15, 2016 at 1:24 PM Felix Fietkau wrote:
> On 2016-02-15 12:19, Eyal Birger wrote:
> > Hi Felix,
> >
> > Thanks for your review!
> >
> > If I understood the code corre
Felix Fietkau wrote:
> On 2016-02-15 12:19, Eyal Birger wrote:
> > Hi Felix,
> >
> > Thanks for your review!
> >
> > If I understood the code correctly, the header fields are never accessed
> > before the header is fully received - at which point the conv
changing their semantics to avoid
backporting messes...
Could you elaborate on the corner cases? are there any tests I can run to
verify them?
Thanks again!
Eyal.
On Mon, Feb 15, 2016 at 12:05 PM Felix Fietkau wrote:
> On 2016-02-15 05:09, Eyal Birger wrote:
> > Changing the ubus messa
9,fork UNIX:/var/run/ubus.sock &
On host B (e.g. little endian development PC) run:
$ socat UNIX-LISTEN:/var/run/ubus.sock,fork TCP::5699 &
Now ubus applications can be run on host B and seamlessly interact with ubus
applications on host A.
Signed-off-by: Eyal Birger
v2:
Applied
9,fork UNIX:/var/run/ubus.sock &
On host B (e.g. little endian development PC) run:
$ socat UNIX-LISTEN:/var/run/ubus.sock,fork TCP::5699 &
Now ubus applications can be run on host B and seamlessly interact with ubus
applications on host A.
Signed-off-by: Eyal Birger
---
libubus-io.c |
17 matches
Mail list logo
