[PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
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  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
> 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
. 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.
 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
More information about the openwrt-devel