On Sat, Jun 4, 2016 at 6:27 PM, Matthias Schiffer <mschif...@universe-factory.net> wrote: > On 06/03/2016 04:55 PM, Eyal Birger wrote: >> >> Hi, >> >>> On 3 Jun 2016, at 13:11, Matthias Schiffer <mschif...@universe-factory.net> >>> 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 converting json strings >> to blobmsg, integers become signed and thus no more than INT32_MAX can be >> used. >> >> Do you plans to approach this in your patchsets? >> >> Eyal > > I don't think this can be fixed easily without having to adjust all > blobmsg_json users, as the blobmsg_policy entries contain > BLOBMSG_TYPE_INT32 everywhere. I don't know how much the ubus methods are > considered unchangeable ABI. > > Possible approaches include: > > 1) Always map JSON intergers to int64. Will cause an incompatible ABI > change for all ubus calls when used with blobmsg_json. > > 2) Add new blobmsg_add_json_* functions which use int64. The caller of a > ubus method would need to know if the service excepts int32 or int64 > integers, making this more or less unusable for the ubus CLI tool > > 3) Adjust blobmsg_add_json_* to encode integers as int32 or int64 depending > on the value itself. We'd need to extend the blobmsg_policy with some kind > of BLOBMSG_TYPE_INT which accepts both int32 and int64, and add a > blobmsg_get_int function that can work with different lengths. Existing > software would continue to work as long as the supplied values fit into an > int32. >
Alas, I think this may still cause an ABI change, as the current int32 implementation caps values at INT32_MAX; so when BLOBMSG_TYPE_INT32 is specified in the policy, a value is _always_ available, whereas in this solution, sometimes it won't be. Am I wrong? > 4) Introduce a new BLOBMSG_TYPE_INT type for variable-length integers, > together with a blobmsg_get_int function (note that, in contrast to 3), > BLOBMSG_TYPE_INT is a real blobmsg type in this approach). The length of > records is encoded in the blobmsg format already. Again, this approach > would need all software to be adjusted. > > 1) and 4) are very similar and would cause a hard ABI break for many ubus > methods. If we want to avoid a flagday change, 3) seems like the best > option - or some other approach I haven't listed? > I tried to think of a way in which we can have blobmsg_format_element() encode *both* int32 and int64 values at the same time. It might work for parsing, but won't work with the current serialization code, not to mention that it would be a very ugly hack. Eyal. > Matthias _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
