[PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64

Brian Norris computersforpeace at gmail.com
Thu Jan 5 19:48:43 PST 2023


On Thu, Jan 5, 2023 at 7:12 PM Stefan Lippers-Hollmann <s.l-h at gmx.de> wrote:
> On 2023-01-06, Christian Marangi wrote:
> > On Thu, Jan 05, 2023 at 02:03:24PM -0800, Brian Norris wrote:
> > > On Thu, Jan 5, 2023 at 11:59 AM Brian Norris
> [...]
> > > Do I need to create some intermediate/stub package just to express the
> > > dependency, or is there some better way?
> > >
> >
> > In theory there is [1] coreutils-base64 as a separate package but I
> > think we have to move that to core packages as it's part of the feeds
> > package.

coreutils definitely works. (busybox would too, except I just can't
get the dependency mechanics right.)

> There would be another alternative for base64 functionality, openssl...
> While not the lightest package, it's already available in main and
> with DEVICE_PACKAGES a relatively low-maintenance alternative.
>
> openssl enc -base64 -in foo -out foo.base64
> openssl enc -d -base64 -in foo.base64 -out foo

I have to throw "-A" in there apparently, since openssl is apparently
too strict on (lack of) line wrapping in the data source, but that
works too.

> With root/ overlay on eMMC, this shouldn't be too heavy for this
> kind of hardware.

Yeah, should be no big deal on space. These devices have ~4GB storage
[1]. Does anybody care on non-disk-space grounds? Like "lack of
choice"? (I guess one can install multiple SSL libraries.)

So what do you all think? Pick my favorite? I suppose I kinda like the
'base64' (either coreutils or busybox) option, since it's a bit of a
simpler tool, and has multiple options (in case somebody is trying to
slim things for some reason). But openssl is easiest from a friction
point of view, since it's just a DEVICE_PACKAGES dependency away,
instead of porting over something from feeds.

Brian

[1] Although the default partitioning sets
CONFIG_TARGET_ROOTFS_PARTSIZE=200, which limits the default build
unnecessarily to ~128MiB. I still need to figure out the best way to
fix that:
https://openwrt.org/toh/google/wifi#expanding_storage_optional



More information about the openwrt-devel mailing list