RFC: Too much json code in rootfs

For Developers
1

This is a copy of my post to the OpenWRT mail list which seems to be rarely read and answered.

While tuning my firmware build for a very resource constrained router, I've
noticed that there are several json-related shared libraries:

  1. libjson-c
  2. libblobmsg_json
  3. libjson_script
  4. libjansson

and maybe even more.

I understand that some of them are built on top of each other but
libjson-c and libjansson seem to provide almost the same
functionality. libjansson comes from libnftables and this dependency
is pretty hard to break because libnftables heavily utilizes the
json_pack feature of jansson which is absent in libjson-c.

But it seems that libjson-c has nothing that can't be taken from
jansson. libnftables dependency is quite fundamental and can't be
avoided. But it seems that the other stuff can be switched to jansson.

Also I’ve noticed that jansson has a smaller footprint than libjson-c which is an addition pro.

Are there any plans to do it?

1 Like
2

Don't know the answer on your question. But I know libucode is dependent on libjson-c, and it does not only use it's json en-/decoding functions, but also it's internal object database functions. (a ucode object is more or less an extended json object)

2 Likes
3

This is likely a situation where if you want it to happen, you'll likely have to make it happen yourself.

There might be some traps in your current comparisons. Are you sure the jansson library size you're comparing to libjson-c hasn't been trimmed in some way to reduce the features that it exposes? (in which case it's not an apples-to-apples comparison).

What kind of FLASH space would be saved if all of the libraries uses were consolidated to use a single library (picking the largest current library seems like the best analysis until proven all the others can offer the same feature set)?

1 Like
4

This is not a feature request. This is a discussion to gather opinions. I don’t want to do it if it won’t be supported by the core developers and will be just thrown away. I’ve already opened several PRs and it is almost a week now and there are just no reactions, reviews or comments. Maybe I should write somewhere to get some attention?

I don’t see any feature-dropping options in its Makefile:

CMAKE_OPTIONS += \
	-DJANSSON_BUILD_DOCS:BOOL=OFF \
	-DJANSSON_BUILD_SHARED_LIBS:BOOL=ON \
	-DJANSSON_EXAMPLES:BOOL=OFF \
	-DJANSSON_WITHOUT_TESTS:BOOL=ON

It is hard to tell because of the recent relro stuff that blows the object files up to the next 64kb alignment. But without relro libjson-c.so consumes 50Kb of FLASH. I’m not sure if the other way, I mean the transition of libnftables to libjson-c is practical because this is a very big external project - I’m being skeptical if they will take this changes upstream. But anyway If we drop libjannson in favor or libjson-c that would give us 35Kb.

1 Like
5

Ok, thanks for you insight. I’ll dive into it to investigate how this database works

6

Casn you link to ML post?
Obviously what you expect is not possible, unless YOU rewrite nftables.

7

Please read carefully - I’m not going to rewrite nftables. Instead I’m offering to migrate the OpenWRT stuff (libblobmsg-json, libjson_script, jsnh etc) to jansson - the same lib that is used by nftables.

They are pretty much the same by functionally and performance while jansson has more clean API (IMHO), provides json_pack API (ATM I’m not sure if OpenWRT can profit from it) and has less footprint than libjson-c

1 Like