Re: [PATCH fstools v2] partname: Ignore root=PARTUUID...
On Mon, Jan 9, 2023 at 3:20 PM Christian Marangi wrote: > On Mon, Jan 09, 2023 at 02:34:48PM -0800, Brian Norris wrote: > > On Mon, Jan 9, 2023 at 1:53 PM Christian Marangi > > wrote: > > > > > > On Fri, Jan 06, 2023 at 06:04:22PM -0800, Brian Norris wrote: > > > > We're assuming all root= arguments are /dev/ paths, but many targets > > > > utilize root=PARTUUID= strategies. At least allow them to fall back > > > > to scanning all block devices. > > > > > > > > Signed-off-by: Brian Norris > > > > > > Can you elaborate this a bit more? > > > > This function currently assumes that if it can find a "root=" line, > > then it can parse it and use it to find "rootfs_data" on the same > > disk. But the rootdevname() function really chokes (does completely > > the wrong thing) when given "PARTUUID=". So this parser becomes > > useless. > > > > > This is dependent of the google based > > > devices with ipq806x but why? > > > > I guess it's not *strictly* a dependency, but as-is, things aren't great. > > > > With the above choking, I believe fstools will fall back to > > rootdisk.c, which will place rootfs_data in a different place -- > > appended to the squashfs filesystem, via a custom loopback device. > > This works OK I suppose, but has its downsides. > > > > But the real kicker is that if fstools / partname.c eventually learns > > how to find the right 'rootfs_data' partition, then suddenly our data > > filesystem will move, and that's not great for sysupgrade. So I'd like > > to get it right from the start, rather than change between rootdisk.c > > and partname.c approaches arbitrarily. > > > > > In theory we should have other device with sd card/eMMC that use uuid to > > > select the partition... > > > > Right. Search the tree for the "root=PARTUUID=" string, and you'll > > find several. (Some breadcrumbs in rockchip, x86, imx, and more.) > > Presumably they would run into the same problem if they tried to use a > > dedicated data partition on a block device -- right now, I believe > > Rockchip restricts itself to a 2-partition layout, for instance. Which > > is why I didn't specifically call this a ipq806x / Google-specific > > thing. > > > > This is what gets me most confused... The patch is correct and looks > good... Just what I can't understand is how things worked till today... > > They all fallback to rootdisk.c? It's worth to check and have some proof > of this theory. > > Since we are playing with the function mounting root the main concern > here is that we brake any device using PARTUUID that somehow are working > now so we need to be carefull in what we change as the risk of causing > regression is behind the corner. Totally understood. > So we should just find a way to understand why thing are working (or are > not working and are using an alternative way currently) Just that and > this can be merged. I don't have any of these targets. (I suppose I could try to figure out how, if at all, the x86/generic target is handling this. But it seems like a very flexible target that can be used in many ways, and I'm not sure I'd find the Right(TM) ones to test.) But looking at sources, I see imx (Build/imx-combined-image) and rockchip (Build/pine64-img) are doing 2-partition layouts, with $(SCRIPT_DIR)/gen_image_generic.sh. So that skips "partname" and just does "rootdisk". On the other hand, Device/glinet_gl-b2200 is one of the few I could find with a 3-partition (with rootfs_data partition) layout (qsdk-ipq-app-gpt), and it has an explicit "root=/dev/mmcblk0p2" in its bootargs. (A related key point: it's the only one using `CI_DATAPART` for emmc.sh sysupgrade.) Most (all?) remaining rootfs_data references I see are related to MTD/UBI, and shouldn't really be relevant. So I don't have a full proof of it, but it appears that all relevant users are either 2-partition layouts that use rootdisk.c, or else using partname.c with a rootfs_data partition but only using /dev paths for root=. Exceptions would be if someone was manually modifying their partition layout with a spare rootfs_data partition, in which case it's possible this could pick it up now. I'm not sure we can guard against all local customizations though. I can try to look or play around some more, if you have hints on what I should investigate. Or wait around for someone (Daniel?) who has more background in this area? > > > Also can't we just ignore the device bootargs > > > and provide a custom one? > > > > This isn't about the device (as in, baked into a bootloader) bootargs; > > see "root=PARTUUID=%U/PARTNROFF=1" in my patch 7: > > https://patchwork.ozlabs.org/project/openwrt/patch/20230107074945.2140362-7-computersforpe...@gmail.com/ > > This is a better way of specifying root devices (say, rather than > > memorizing a "/dev/mmcblk0" or similar, which is *not* a stable > > contract; it also means boot-from-USB won't work), except that fstools > > doesn't like it. (And again, there are several other existing > > openwrt.git users
Re: [PATCH fstools v2] partname: Ignore root=PARTUUID...
On Mon, Jan 09, 2023 at 02:34:48PM -0800, Brian Norris wrote:
> On Mon, Jan 9, 2023 at 1:53 PM Christian Marangi wrote:
> >
> > On Fri, Jan 06, 2023 at 06:04:22PM -0800, Brian Norris wrote:
> > > We're assuming all root= arguments are /dev/ paths, but many targets
> > > utilize root=PARTUUID= strategies. At least allow them to fall back
> > > to scanning all block devices.
> > >
> > > Signed-off-by: Brian Norris
> >
> > Can you elaborate this a bit more?
>
> This function currently assumes that if it can find a "root=" line,
> then it can parse it and use it to find "rootfs_data" on the same
> disk. But the rootdevname() function really chokes (does completely
> the wrong thing) when given "PARTUUID=". So this parser becomes
> useless.
>
> > This is dependent of the google based
> > devices with ipq806x but why?
>
> I guess it's not *strictly* a dependency, but as-is, things aren't great.
>
> With the above choking, I believe fstools will fall back to
> rootdisk.c, which will place rootfs_data in a different place --
> appended to the squashfs filesystem, via a custom loopback device.
> This works OK I suppose, but has its downsides.
>
> But the real kicker is that if fstools / partname.c eventually learns
> how to find the right 'rootfs_data' partition, then suddenly our data
> filesystem will move, and that's not great for sysupgrade. So I'd like
> to get it right from the start, rather than change between rootdisk.c
> and partname.c approaches arbitrarily.
>
> > In theory we should have other device with sd card/eMMC that use uuid to
> > select the partition...
>
> Right. Search the tree for the "root=PARTUUID=" string, and you'll
> find several. (Some breadcrumbs in rockchip, x86, imx, and more.)
> Presumably they would run into the same problem if they tried to use a
> dedicated data partition on a block device -- right now, I believe
> Rockchip restricts itself to a 2-partition layout, for instance. Which
> is why I didn't specifically call this a ipq806x / Google-specific
> thing.
>
This is what gets me most confused... The patch is correct and looks
good... Just what I can't understand is how things worked till today...
They all fallback to rootdisk.c? It's worth to check and have some proof
of this theory.
Since we are playing with the function mounting root the main concern
here is that we brake any device using PARTUUID that somehow are working
now so we need to be carefull in what we change as the risk of causing
regression is behind the corner.
So we should just find a way to understand why thing are working (or are
not working and are using an alternative way currently) Just that and
this can be merged.
> > Also can't we just ignore the device bootargs
> > and provide a custom one?
>
> This isn't about the device (as in, baked into a bootloader) bootargs;
> see "root=PARTUUID=%U/PARTNROFF=1" in my patch 7:
> https://patchwork.ozlabs.org/project/openwrt/patch/20230107074945.2140362-7-computersforpe...@gmail.com/
> This is a better way of specifying root devices (say, rather than
> memorizing a "/dev/mmcblk0" or similar, which is *not* a stable
> contract; it also means boot-from-USB won't work), except that fstools
> doesn't like it. (And again, there are several other existing
> openwrt.git users for it.)
>
I understand and I want this fixed. Sorry if I look confused but you can
understand how this was broken from ages and still we have many target
using the root=PARTUUID format makes me question a lot of thing ahahhaha
>
> > > ---
> > >
> > > Changes in v2:
> > > * fstools, not fsutils (sorry for the noise)
> > >
> > > libfstools/partname.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libfstools/partname.c b/libfstools/partname.c
> > > index f59c52eb8f3c..9c27015643ad 100644
> > > --- a/libfstools/partname.c
> > > +++ b/libfstools/partname.c
> > > @@ -128,12 +128,12 @@ static struct volume *partname_volume_find(char
> > > *name)
> > > return NULL;
> > > }
> > >
> > > - if (get_var_from_file("/proc/cmdline", "root", rootparam,
> > > sizeof(rootparam))) {
> > > + if (get_var_from_file("/proc/cmdline", "root", rootparam,
> > > sizeof(rootparam)) && rootparam[0] == '/') {
> > > rootdev = rootdevname(rootparam);
> > > /* find partition on same device as rootfs */
> > > snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent",
> > > block_dir_name, rootdev);
> > > } else {
> > > - /* no 'root=' kernel cmdline parameter, find on any block
> > > device */
> > > + /* no useful 'root=' kernel cmdline parameter, find on any
> > > block device */
> > > snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent",
> > > block_dir_name);
> > > }
> > >
> > > --
> > > 2.39.0
> > >
> > >
> > > ___
> > > openwrt-devel mailing list
> > > openwrt-devel@lists.openwrt.org
> > >
Re: [PATCH fstools v2] partname: Ignore root=PARTUUID...
On Mon, Jan 9, 2023 at 1:53 PM Christian Marangi wrote:
>
> On Fri, Jan 06, 2023 at 06:04:22PM -0800, Brian Norris wrote:
> > We're assuming all root= arguments are /dev/ paths, but many targets
> > utilize root=PARTUUID= strategies. At least allow them to fall back
> > to scanning all block devices.
> >
> > Signed-off-by: Brian Norris
>
> Can you elaborate this a bit more?
This function currently assumes that if it can find a "root=" line,
then it can parse it and use it to find "rootfs_data" on the same
disk. But the rootdevname() function really chokes (does completely
the wrong thing) when given "PARTUUID=". So this parser becomes
useless.
> This is dependent of the google based
> devices with ipq806x but why?
I guess it's not *strictly* a dependency, but as-is, things aren't great.
With the above choking, I believe fstools will fall back to
rootdisk.c, which will place rootfs_data in a different place --
appended to the squashfs filesystem, via a custom loopback device.
This works OK I suppose, but has its downsides.
But the real kicker is that if fstools / partname.c eventually learns
how to find the right 'rootfs_data' partition, then suddenly our data
filesystem will move, and that's not great for sysupgrade. So I'd like
to get it right from the start, rather than change between rootdisk.c
and partname.c approaches arbitrarily.
> In theory we should have other device with sd card/eMMC that use uuid to
> select the partition...
Right. Search the tree for the "root=PARTUUID=" string, and you'll
find several. (Some breadcrumbs in rockchip, x86, imx, and more.)
Presumably they would run into the same problem if they tried to use a
dedicated data partition on a block device -- right now, I believe
Rockchip restricts itself to a 2-partition layout, for instance. Which
is why I didn't specifically call this a ipq806x / Google-specific
thing.
> Also can't we just ignore the device bootargs
> and provide a custom one?
This isn't about the device (as in, baked into a bootloader) bootargs;
see "root=PARTUUID=%U/PARTNROFF=1" in my patch 7:
https://patchwork.ozlabs.org/project/openwrt/patch/20230107074945.2140362-7-computersforpe...@gmail.com/
This is a better way of specifying root devices (say, rather than
memorizing a "/dev/mmcblk0" or similar, which is *not* a stable
contract; it also means boot-from-USB won't work), except that fstools
doesn't like it. (And again, there are several other existing
openwrt.git users for it.)
Brian
> > ---
> >
> > Changes in v2:
> > * fstools, not fsutils (sorry for the noise)
> >
> > libfstools/partname.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libfstools/partname.c b/libfstools/partname.c
> > index f59c52eb8f3c..9c27015643ad 100644
> > --- a/libfstools/partname.c
> > +++ b/libfstools/partname.c
> > @@ -128,12 +128,12 @@ static struct volume *partname_volume_find(char *name)
> > return NULL;
> > }
> >
> > - if (get_var_from_file("/proc/cmdline", "root", rootparam,
> > sizeof(rootparam))) {
> > + if (get_var_from_file("/proc/cmdline", "root", rootparam,
> > sizeof(rootparam)) && rootparam[0] == '/') {
> > rootdev = rootdevname(rootparam);
> > /* find partition on same device as rootfs */
> > snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent",
> > block_dir_name, rootdev);
> > } else {
> > - /* no 'root=' kernel cmdline parameter, find on any block
> > device */
> > + /* no useful 'root=' kernel cmdline parameter, find on any
> > block device */
> > snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent",
> > block_dir_name);
> > }
> >
> > --
> > 2.39.0
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> --
> Ansuel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH fstools v2] partname: Ignore root=PARTUUID...
On Fri, Jan 06, 2023 at 06:04:22PM -0800, Brian Norris wrote:
> We're assuming all root= arguments are /dev/ paths, but many targets
> utilize root=PARTUUID= strategies. At least allow them to fall back
> to scanning all block devices.
>
> Signed-off-by: Brian Norris
Can you elaborate this a bit more? This is dependent of the google based
devices with ipq806x but why?
In theory we should have other device with sd card/eMMC that use uuid to
select the partition... Also can't we just ignore the device bootargs
and provide a custom one?
> ---
>
> Changes in v2:
> * fstools, not fsutils (sorry for the noise)
>
> libfstools/partname.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libfstools/partname.c b/libfstools/partname.c
> index f59c52eb8f3c..9c27015643ad 100644
> --- a/libfstools/partname.c
> +++ b/libfstools/partname.c
> @@ -128,12 +128,12 @@ static struct volume *partname_volume_find(char *name)
> return NULL;
> }
>
> - if (get_var_from_file("/proc/cmdline", "root", rootparam,
> sizeof(rootparam))) {
> + if (get_var_from_file("/proc/cmdline", "root", rootparam,
> sizeof(rootparam)) && rootparam[0] == '/') {
> rootdev = rootdevname(rootparam);
> /* find partition on same device as rootfs */
> snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent",
> block_dir_name, rootdev);
> } else {
> - /* no 'root=' kernel cmdline parameter, find on any block
> device */
> + /* no useful 'root=' kernel cmdline parameter, find on any
> block device */
> snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent",
> block_dir_name);
> }
>
> --
> 2.39.0
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Ansuel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Mon, Jan 09, 2023 at 12:23:25PM -0800, Brian Norris wrote:
> On Mon, Jan 9, 2023 at 11:56 AM Christian Marangi
> wrote:
> > On Mon, Jan 09, 2023 at 11:51:53AM -0800, Brian Norris wrote:
> > > For my use, it feels like a simplified form (which only needs to be a
> > > stdin/stdout pipeline) would be pretty easy to inline into the
> > > caldata/firmware-loader script:
> > >
> > > ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
> > >
> >
> > Ok a single line solution will be ideal and easy to include in the
> > hotplug script.
>
> Sounds good.
>
> > > > 2. Ucode is part of the core packages? Or an optional dependency for
> > > > luci and fw4? In theory it should be always present or as a safe thing
> > > > we should add ucode in the required packages for this target?
> > >
> > > So far I don't find it as a strict core dependency, but just happens
> > > to be available by default due to dependencies. I guess similar
> > > questions to the busybox, coreutils, etc., stuff -- whether we're OK
> > > with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES.
> > >
> >
> > If it's not a strict core dependency I would just put ucode as a
> > dependency for the needed devices and be done with it. It's not a low
> > space target and ucode is not that big and for sure smaller than lua,
> > openssl and easier to implement than moving coreutils from feeds to
> > core.
>
> Sounds good to me.
>
> Thanks all for the help.
>
> > Think with v3 and this implemented the series is ready.
>
> Great! Unfortunately, I'm still dependent on an outstanding patch for
> the fstools project:
> https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpe...@gmail.com/
> See also patch 7's notes.
>
> I guess I could revert to the 2-partition layout (which does not
> depend on the fstools change) for the time being, so snapshots would
> work. I'm still trying to figure out what the best partitioning and
> syupgrade strategy is best for disk space flexibility and for
> reliability (e.g., not clobbering rootfs_data when it's appended to
> rootfs) on block devices...
>
We have way to make old image not compatible with partition change and
stuff so migrating to a new implementation in the future won't be that
problematic.
But it would be good if we can sort it out before... Need to check that
fstool patch better and see if something can be done.
--
Ansuel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH v2] devices: add support for declaring compatible matched devices
On Mon, Jan 09, 2023 at 09:58:19PM +0100, Andre Heider wrote: > On 09/01/2023 21:44, Andre Heider wrote: > > On 09/01/2023 20:49, Christian Marangi wrote: > > > From: Jo-Philipp Wich > > > > > > Some device have embedded wifi card that are not connected with usb or > > > internall with pci. Such device have fake device_id and only the > > > vendor_id actually reflect something real but internally they don't have > > > any id and are just matched by the node compatible binding in DT. > > > > > > We currently match this with a big if-else to match the single devices > > > but this can be improved and be matched directly in devices.txt > > > > > > Rework this so that we can drop the big if-else and move the matching > > > to devices.txt > > > > > > When a device is matched using compatible in iwinfo the hardware will be > > > flagged as embedded and won't print empty ids. > > > > > > Update devices.txt by migrating all the compatible matching device from > > > fake id to compatible matching. > > > > > > Tested-by: Christian Marangi # ipq4019 > > > Co-developed-by: Christian Marangi > > > Signed-off-by: Jo-Philipp Wich > > > Signed-off-by: Christian Marangi > > > Tested-by: Robert Marko # ipq8074 > > > > Reviewed-by: Andre Heider > > Forgot to mention, but stating the obvious: > This changes the ABI (adding new members to public structs), so a > recompilation of all users is sufficient to avoid problems. Hence, please > bump IWINFO_ABI_VERSION once this is merged and the package gets updated. > Need jow help for this... There is an intention to not change ABI version if not really needed... > While on that topic, the few remaining patches from PR#11280 are in the same > boat. Can we get those merged too, pretty please? > -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH v2] devices: add support for declaring compatible matched devices
On 09/01/2023 21:44, Andre Heider wrote: On 09/01/2023 20:49, Christian Marangi wrote: From: Jo-Philipp Wich Some device have embedded wifi card that are not connected with usb or internall with pci. Such device have fake device_id and only the vendor_id actually reflect something real but internally they don't have any id and are just matched by the node compatible binding in DT. We currently match this with a big if-else to match the single devices but this can be improved and be matched directly in devices.txt Rework this so that we can drop the big if-else and move the matching to devices.txt When a device is matched using compatible in iwinfo the hardware will be flagged as embedded and won't print empty ids. Update devices.txt by migrating all the compatible matching device from fake id to compatible matching. Tested-by: Christian Marangi # ipq4019 Co-developed-by: Christian Marangi Signed-off-by: Jo-Philipp Wich Signed-off-by: Christian Marangi Tested-by: Robert Marko # ipq8074 Reviewed-by: Andre Heider Forgot to mention, but stating the obvious: This changes the ABI (adding new members to public structs), so a recompilation of all users is sufficient to avoid problems. Hence, please bump IWINFO_ABI_VERSION once this is merged and the package gets updated. While on that topic, the few remaining patches from PR#11280 are in the same boat. Can we get those merged too, pretty please? Thanks, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH v2] devices: add support for declaring compatible matched devices
On 09/01/2023 20:49, Christian Marangi wrote: From: Jo-Philipp Wich Some device have embedded wifi card that are not connected with usb or internall with pci. Such device have fake device_id and only the vendor_id actually reflect something real but internally they don't have any id and are just matched by the node compatible binding in DT. We currently match this with a big if-else to match the single devices but this can be improved and be matched directly in devices.txt Rework this so that we can drop the big if-else and move the matching to devices.txt When a device is matched using compatible in iwinfo the hardware will be flagged as embedded and won't print empty ids. Update devices.txt by migrating all the compatible matching device from fake id to compatible matching. Tested-by: Christian Marangi # ipq4019 Co-developed-by: Christian Marangi Signed-off-by: Jo-Philipp Wich Signed-off-by: Christian Marangi Tested-by: Robert Marko # ipq8074 Reviewed-by: Andre Heider ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Mon, Jan 9, 2023 at 11:56 AM Christian Marangi wrote:
> On Mon, Jan 09, 2023 at 11:51:53AM -0800, Brian Norris wrote:
> > For my use, it feels like a simplified form (which only needs to be a
> > stdin/stdout pipeline) would be pretty easy to inline into the
> > caldata/firmware-loader script:
> >
> > ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
> >
>
> Ok a single line solution will be ideal and easy to include in the
> hotplug script.
Sounds good.
> > > 2. Ucode is part of the core packages? Or an optional dependency for
> > > luci and fw4? In theory it should be always present or as a safe thing
> > > we should add ucode in the required packages for this target?
> >
> > So far I don't find it as a strict core dependency, but just happens
> > to be available by default due to dependencies. I guess similar
> > questions to the busybox, coreutils, etc., stuff -- whether we're OK
> > with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES.
> >
>
> If it's not a strict core dependency I would just put ucode as a
> dependency for the needed devices and be done with it. It's not a low
> space target and ucode is not that big and for sure smaller than lua,
> openssl and easier to implement than moving coreutils from feeds to
> core.
Sounds good to me.
Thanks all for the help.
> Think with v3 and this implemented the series is ready.
Great! Unfortunately, I'm still dependent on an outstanding patch for
the fstools project:
https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpe...@gmail.com/
See also patch 7's notes.
I guess I could revert to the 2-partition layout (which does not
depend on the fstools change) for the time being, so snapshots would
work. I'm still trying to figure out what the best partitioning and
syupgrade strategy is best for disk space flexibility and for
reliability (e.g., not clobbering rootfs_data when it's appended to
rootfs) on block devices...
Brian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Mon, Jan 09, 2023 at 11:51:53AM -0800, Brian Norris wrote:
> On Mon, Jan 9, 2023 at 11:21 AM Christian Marangi
> wrote:
> >
> > On Mon, Jan 09, 2023 at 03:35:56PM +0100, Petr Štetiar wrote:
> > > Petr Štetiar [2023-01-09 11:50:37]:
> > >
> > > Hi,
> > >
> > > > BTW ucode has `b64dec()`[1] so perhaps another viable option.
> > > >
> > > > 1. https://github.com/jow-/ucode#663-b64decstr
> > >
> > > wanted to refresh my ucode brain cells, so I've explored feasibility of
> > > that
> > > suggestion and it seems to work just fine:
> > >
> > > #!/usr/bin/ucode
> > >
> > > import { stdin, open, error } from 'fs';
> > >
> > > if (length(ARGV) == 0 && stdin.isatty()) {
> > > warn("usage: b64decode [stdin|path]\n");
> > > exit(1);
> > > }
> > >
> > > let fp = stdin;
> > > let source = ARGV[0];
> > >
> > > if (source) {
> > > fp = open(source);
> > > if (!fp) {
> > > warn(`b64decode: unable to open ${source}:
> > > ${error()}\n`);
> > > exit(1);
> > > }
> > > }
> > >
> > > print(b64dec(fp.read("all")));
> > > fp.close();
> > > exit(0);
> > >
> > > BTW it needs recent ucode with fs.stdin.isatty() support[1].
> > >
> > > Thanks Jo for helping me making above script more idiomatic. IMO it looks
> > > more
> > > human readable, portable and maintanable then that awk based solution.
> > >
> > > 1.
> > > https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1
>
> I sidestepped the isatty() stuff (below), and this works for me too.
>
> > Thanks for helping with this. I really like the ucode way. Just a few
> > question:
> > 1. How this should be handled? A script that the target will provide?
> > Part of a common function?
>
> For my use, it feels like a simplified form (which only needs to be a
> stdin/stdout pipeline) would be pretty easy to inline into the
> caldata/firmware-loader script:
>
> ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
>
Ok a single line solution will be ideal and easy to include in the
hotplug script.
> > 2. Ucode is part of the core packages? Or an optional dependency for
> > luci and fw4? In theory it should be always present or as a safe thing
> > we should add ucode in the required packages for this target?
>
> So far I don't find it as a strict core dependency, but just happens
> to be available by default due to dependencies. I guess similar
> questions to the busybox, coreutils, etc., stuff -- whether we're OK
> with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES.
>
If it's not a strict core dependency I would just put ucode as a
dependency for the needed devices and be done with it. It's not a low
space target and ucode is not that big and for sure smaller than lua,
openssl and easier to implement than moving coreutils from feeds to
core.
Think with v3 and this implemented the series is ready.
--
Ansuel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Mon, Jan 9, 2023 at 11:21 AM Christian Marangi wrote:
>
> On Mon, Jan 09, 2023 at 03:35:56PM +0100, Petr Štetiar wrote:
> > Petr Štetiar [2023-01-09 11:50:37]:
> >
> > Hi,
> >
> > > BTW ucode has `b64dec()`[1] so perhaps another viable option.
> > >
> > > 1. https://github.com/jow-/ucode#663-b64decstr
> >
> > wanted to refresh my ucode brain cells, so I've explored feasibility of that
> > suggestion and it seems to work just fine:
> >
> > #!/usr/bin/ucode
> >
> > import { stdin, open, error } from 'fs';
> >
> > if (length(ARGV) == 0 && stdin.isatty()) {
> > warn("usage: b64decode [stdin|path]\n");
> > exit(1);
> > }
> >
> > let fp = stdin;
> > let source = ARGV[0];
> >
> > if (source) {
> > fp = open(source);
> > if (!fp) {
> > warn(`b64decode: unable to open ${source}:
> > ${error()}\n`);
> > exit(1);
> > }
> > }
> >
> > print(b64dec(fp.read("all")));
> > fp.close();
> > exit(0);
> >
> > BTW it needs recent ucode with fs.stdin.isatty() support[1].
> >
> > Thanks Jo for helping me making above script more idiomatic. IMO it looks
> > more
> > human readable, portable and maintanable then that awk based solution.
> >
> > 1.
> > https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1
I sidestepped the isatty() stuff (below), and this works for me too.
> Thanks for helping with this. I really like the ucode way. Just a few
> question:
> 1. How this should be handled? A script that the target will provide?
> Part of a common function?
For my use, it feels like a simplified form (which only needs to be a
stdin/stdout pipeline) would be pretty easy to inline into the
caldata/firmware-loader script:
ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
> 2. Ucode is part of the core packages? Or an optional dependency for
> luci and fw4? In theory it should be always present or as a safe thing
> we should add ucode in the required packages for this target?
So far I don't find it as a strict core dependency, but just happens
to be available by default due to dependencies. I guess similar
questions to the busybox, coreutils, etc., stuff -- whether we're OK
with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES.
Brian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[iwinfo PATCH v2] devices: add support for declaring compatible matched devices
From: Jo-Philipp Wich
Some device have embedded wifi card that are not connected with usb or
internall with pci. Such device have fake device_id and only the
vendor_id actually reflect something real but internally they don't have
any id and are just matched by the node compatible binding in DT.
We currently match this with a big if-else to match the single devices
but this can be improved and be matched directly in devices.txt
Rework this so that we can drop the big if-else and move the matching
to devices.txt
When a device is matched using compatible in iwinfo the hardware will be
flagged as embedded and won't print empty ids.
Update devices.txt by migrating all the compatible matching device from
fake id to compatible matching.
Tested-by: Christian Marangi # ipq4019
Co-developed-by: Christian Marangi
Signed-off-by: Jo-Philipp Wich
Signed-off-by: Christian Marangi
Tested-by: Robert Marko # ipq8074
---
devices.txt | 23 +---
include/iwinfo.h | 2 ++
iwinfo_cli.c | 9 --
iwinfo_nl80211.c | 71 ++--
iwinfo_utils.c | 8 +-
5 files changed, 36 insertions(+), 77 deletions(-)
diff --git a/devices.txt b/devices.txt
index d76bbca..4da663d 100644
--- a/devices.txt
+++ b/devices.txt
@@ -141,7 +141,6 @@
0x168c 0x002a 0x0777 0xe202 12 0 "Ubiquiti" "Bullet M2"
0x168c 0x002a 0x0777 0xe8055 0 "Ubiquiti" "Bullet M5"
0x168c 0x002a 0x0777 0xe3450 0 "Ubiquiti" "WispStation M5" /* ToDo:
confirm offset - Wrong! */
-0x168c 0x0029 0x168c 0x91300 0 "Atheros" "AR9130"
0x168c 0x0029 0x168c 0xa0940 0 "Atheros" "AR9220"
0x168c 0x0029 0x168c 0xa0950 0 "Atheros" "AR9223"
0x168c 0x002a 0x168c 0xa0930 0 "Atheros" "AR9280"
@@ -151,11 +150,6 @@
0x168c 0x002e 0x0777 0xe0a28 0 "Ubiquiti" "NanoStation Loco M2 (XM)"
/* wrong offset! */
0x168c 0x002e 0x168c 0x30a40 0 "Atheros" "AR9287"
0x168c 0x0030 0x168c 0x31140 0 "Atheros" "AR9390"
-0x168c 0x0030 0x168c 0x93300 0 "Atheros" "AR9330"
-0x168c 0x0030 0x168c 0x93400 0 "Atheros" "AR9340"
-0x168c 0x0033 0x168c 0x95300 0 "Qualcomm Atheros" "QCA9530"
-0x168c 0x0033 0x168c 0x95500 0 "Qualcomm Atheros" "QCA9550"
-0x168c 0x0033 0x168c 0x95600 0 "Qualcomm Atheros" "QCA9560"
0x168c 0x0033 0x168c 0xa1200 0 "Atheros" "AR9580"
0x168c 0x0033 0x168c 0xa1360 0 "Atheros" "AR9580"
0x168c 0x0033 0x19b6 0xd0140 0 "MikroTik" "R11e-5HnD"
@@ -166,8 +160,6 @@
0x168c 0x003c 0x168c 0x32230 0 "Qualcomm Atheros" "QCA9880"
0x168c 0x003c 0x1a56 0x14200 0 "Qualcomm Atheros" "QCA9862"
0x168c 0x003c 0x19b6 0xd03c0 0 "Mikrotik" "R11e-5HacT"
-0x168c 0x003c 0x168c 0x40190 0 "Qualcomm Atheros" "IPQ4019"
-0x168c 0x8074 0x168c 0x80740 0 "Qualcomm Atheros" "IPQ8074"
0x168c 0x003c 0x19b6 0xd0750 0 "Mikrotik" "R11e-5HacD"
0x168c 0x0040 0x168c 0x00020 0 "Qualcomm Atheros" "QCA9990"
0x168c 0x0046 0x168c 0xcafe0 0 "Qualcomm Atheros" "QCA9984"
@@ -193,12 +185,10 @@
0x14c3 0x7663 0x14c3 0x76630 0 "MediaTek" "MT7613BE"
0x14c3 0x7615 0x7615 0x14c30 0 "MediaTek" "MT7615E"
0x14c3 0x7620 0x14c3 0x000c0 0 "MediaTek" "MT7620"
-0x14c3 0x7622 0x14c3 0x76220 0 "MediaTek" "MT7622"
0x14c3 0x7628 0x14c3 0x00040 0 "MediaTek" "MT76x8"
0x14c3 0x7650 0x14c3 0x76500 0 "MediaTek" "MT7610E"
0x14c3 0x7662 0x14c3 0x76620 0 "MediaTek" "MT76x2E"
0x14c3 0x7915 0x14c3 0x79150 0 "MediaTek" "MT7915E"
-0x14c3 0x7986 0x14c3 0x79860 0 "MediaTek" "MT7986"
0x14e4 0xaa52 0x14e4 0xaa520 0 "Broadcom" "BCM43602"
0x02d0 0xa9a6 0x 0x0 0 "Cypress" "CYW43455"
0x1ae9 0x0310 0x1ae9 0x0 0 "Wilocity" "Wil6210"
@@ -206,3 +196,16 @@
# USB devices
# 0x | 0x | vendor id | product id | ...
0x 0x 0x0e8d 0x79610 0 "MediaTek" "MT7921AU"
+
+# FDT compatible strings
+# "compatible" | txpower offset | frequency offset | ...
+"qca,ar9130-wmac" 0 0 "Atheros" "AR9130"
+"qca,ar9330-wmac" 0 0 "Atheros" "AR9330"
+"qca,ar9340-wmac" 0 0 "Atheros" "AR9340"
+"qca,qca9530-wmac" 0 0 "Qualcomm Atheros" "QCA9530"
+"qca,qca9550-wmac" 0 0 "Qualcomm Atheros" "QCA9550"
+"qca,qca9560-wmac" 0 0 "Qualcomm Atheros" "QCA9560"
+"qcom,ipq4019-wifi" 0 0 "Qualcomm Atheros" "IPQ4019"
+"qcom,ipq8074-wifi" 0 0 "Qualcomm Atheros" "IPQ8074"
+"mediatek,mt7622-wmac" 0 0 "MediaTek" "MT7622"
+"mediatek,mt7986-wmac" 0 0 "MediaTek" "MT7986"
diff --git a/include/iwinfo.h b/include/iwinfo.h
index e87ad18..4b63f1e 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -243,6 +243,7 @@ struct iwinfo_hardware_id {
uint16_t device_id;
uint16_t subsystem_vendor_id;
Re: [iwinfo PATCH] devices: add support for declaring compatible matched devices
On 09/01/2023 20:17, Christian Marangi wrote:
On Mon, Jan 09, 2023 at 08:14:36PM +0100, Andre Heider wrote:
On 09/01/2023 19:58, Christian Marangi wrote:
On Mon, Jan 09, 2023 at 07:53:02PM +0100, Andre Heider wrote:
On 09/01/2023 19:46, Christian Marangi wrote:
On Mon, Jan 09, 2023 at 07:44:34PM +0100, Andre Heider wrote:
On 09/01/2023 18:28, Christian Marangi wrote:
From: Jo-Philipp Wich
Some device have embedded wifi card that are not connected with usb or
internall with pci. Such device have fake device_id and only the
vendor_id actually reflect something real but internally they don't have
any id and are just matched by the node compatible binding in DT.
Nice cleanup! But those fake entries in devices.txt can then be removed,
right? (Assuming all of those _are_ fake and not mapped to actual pci ids)
But they are dropped. Am I missing something? Everything with compatible
doesn't have the id declared and internally they are all set to 0.
The code that maps them to ids is dropped, the id entries mapping those to
the result values are not (which is why this is so ugly ;)
For the first if() that's:
diff --git a/devices.txt b/devices.txt
index e0663b8..040766c 100644
--- a/devices.txt
+++ b/devices.txt
@@ -141,7 +141,6 @@
0x168c 0x002a 0x0777 0xe202 12 0 "Ubiquiti" "Bullet M2"
0x168c 0x002a 0x0777 0xe8055 0 "Ubiquiti" "Bullet M5"
0x168c 0x002a 0x0777 0xe3450 0 "Ubiquiti" "WispStation M5" /*
ToDo: confirm offset - Wrong! */
-0x168c 0x0029 0x168c 0x91300 0 "Atheros" "AR9130"
0x168c 0x0029 0x168c 0xa0940 0 "Atheros" "AR9220"
0x168c 0x0029 0x168c 0xa0950 0 "Atheros" "AR9223"
0x168c 0x002a 0x168c 0xa0930 0 "Atheros" "AR9280"
Still I'm not following... the only place we did compatible matching was
in nl80211_hardware_id_from_fdt. Stuff that was present in devices.txt
is all matched from pci id. Unless they are faked by some driver iwinfo
in theory is using provided pci id to do the match.
If that is not the case then I have no idea how iwinfo is taking the id if
the connected pci card is not providing them.
Happy to fix if you can give me better example but I wasn't aware we had
pci device with fake id. Am I missing a patch on a different place?
Drivers are not faking anything, iwinfo is.
Once upon a time it only supported pci based cards, using the four id
values. Later support for non-pci dt-compatible was hacked in. For that, it
maps those compatible strings to made up pci ids in code, and at the same
time added those fake ids to devices.txt.
Like the recent commit here:
https://git.openwrt.org/?p=project/iwinfo.git;a=commitdiff;h=5914d7113ecf77de63eb21fc233684d1a1a52ca5
This patch cleans that up, but it left out the device entries, which are
dead now.
Hope that clears it up?
OHHH ok yes!
I was aware that iwinfo was faking ids but totally forgot the entry were
still there in devices.txt
Let me send v2 with the entry dropped... Wonder if you can take an extra
check in case I miss some.
Sure.
BTW, not directly related, but mainline linux also supports something
related to map dt wifi devices to pci ids so the desired driver binds:
$ git grep 'compatible = "pci'
...
target/linux/ath79/dts/ar7161_aruba_ap-105.dts- ath9k0: wifi@0,11 { /*
2.4 GHz */
target/linux/ath79/dts/ar7161_aruba_ap-105.dts: compatible =
"pci168c,0029";
...
iwinfo could evaluate those embedded pci ids to then properly match
based on pci instead of dt-compatibles. I don't have a board using that
feature though.
Cheers,
Andre
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Mon, Jan 09, 2023 at 03:35:56PM +0100, Petr Štetiar wrote:
> Petr Štetiar [2023-01-09 11:50:37]:
>
> Hi,
>
> > BTW ucode has `b64dec()`[1] so perhaps another viable option.
> >
> > 1. https://github.com/jow-/ucode#663-b64decstr
>
> wanted to refresh my ucode brain cells, so I've explored feasibility of that
> suggestion and it seems to work just fine:
>
> #!/usr/bin/ucode
>
> import { stdin, open, error } from 'fs';
>
> if (length(ARGV) == 0 && stdin.isatty()) {
> warn("usage: b64decode [stdin|path]\n");
> exit(1);
> }
>
> let fp = stdin;
> let source = ARGV[0];
>
> if (source) {
> fp = open(source);
> if (!fp) {
> warn(`b64decode: unable to open ${source}:
> ${error()}\n`);
> exit(1);
> }
> }
>
> print(b64dec(fp.read("all")));
> fp.close();
> exit(0);
>
> BTW it needs recent ucode with fs.stdin.isatty() support[1].
>
> Thanks Jo for helping me making above script more idiomatic. IMO it looks more
> human readable, portable and maintanable then that awk based solution.
>
> 1.
> https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1
>
Thanks for helping with this. I really like the ucode way. Just a few
question:
1. How this should be handled? A script that the target will provide?
Part of a common function?
2. Ucode is part of the core packages? Or an optional dependency for
luci and fw4? In theory it should be always present or as a safe thing
we should add ucode in the required packages for this target?
--
Ansuel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH] devices: add support for declaring compatible matched devices
On Mon, Jan 09, 2023 at 08:14:36PM +0100, Andre Heider wrote: > On 09/01/2023 19:58, Christian Marangi wrote: > > On Mon, Jan 09, 2023 at 07:53:02PM +0100, Andre Heider wrote: > > > On 09/01/2023 19:46, Christian Marangi wrote: > > > > On Mon, Jan 09, 2023 at 07:44:34PM +0100, Andre Heider wrote: > > > > > On 09/01/2023 18:28, Christian Marangi wrote: > > > > > > From: Jo-Philipp Wich > > > > > > > > > > > > Some device have embedded wifi card that are not connected with usb > > > > > > or > > > > > > internall with pci. Such device have fake device_id and only the > > > > > > vendor_id actually reflect something real but internally they don't > > > > > > have > > > > > > any id and are just matched by the node compatible binding in DT. > > > > > > > > > > Nice cleanup! But those fake entries in devices.txt can then be > > > > > removed, > > > > > right? (Assuming all of those _are_ fake and not mapped to actual pci > > > > > ids) > > > > > > > > > > > > > But they are dropped. Am I missing something? Everything with compatible > > > > doesn't have the id declared and internally they are all set to 0. > > > > > > The code that maps them to ids is dropped, the id entries mapping those to > > > the result values are not (which is why this is so ugly ;) > > > > > > For the first if() that's: > > > > > > diff --git a/devices.txt b/devices.txt > > > index e0663b8..040766c 100644 > > > --- a/devices.txt > > > +++ b/devices.txt > > > @@ -141,7 +141,6 @@ > > > 0x168c 0x002a 0x0777 0xe202 12 0 "Ubiquiti" "Bullet M2" > > > 0x168c 0x002a 0x0777 0xe8055 0 "Ubiquiti" "Bullet M5" > > > 0x168c 0x002a 0x0777 0xe3450 0 "Ubiquiti" "WispStation M5" /* > > > ToDo: confirm offset - Wrong! */ > > > -0x168c 0x0029 0x168c 0x91300 0 "Atheros" "AR9130" > > > 0x168c 0x0029 0x168c 0xa0940 0 "Atheros" "AR9220" > > > 0x168c 0x0029 0x168c 0xa0950 0 "Atheros" "AR9223" > > > 0x168c 0x002a 0x168c 0xa0930 0 "Atheros" "AR9280" > > > > Still I'm not following... the only place we did compatible matching was > > in nl80211_hardware_id_from_fdt. Stuff that was present in devices.txt > > is all matched from pci id. Unless they are faked by some driver iwinfo > > in theory is using provided pci id to do the match. > > > > If that is not the case then I have no idea how iwinfo is taking the id if > > the connected pci card is not providing them. > > > > Happy to fix if you can give me better example but I wasn't aware we had > > pci device with fake id. Am I missing a patch on a different place? > > Drivers are not faking anything, iwinfo is. > > Once upon a time it only supported pci based cards, using the four id > values. Later support for non-pci dt-compatible was hacked in. For that, it > maps those compatible strings to made up pci ids in code, and at the same > time added those fake ids to devices.txt. > > Like the recent commit here: > https://git.openwrt.org/?p=project/iwinfo.git;a=commitdiff;h=5914d7113ecf77de63eb21fc233684d1a1a52ca5 > > This patch cleans that up, but it left out the device entries, which are > dead now. > > Hope that clears it up? OHHH ok yes! I was aware that iwinfo was faking ids but totally forgot the entry were still there in devices.txt Let me send v2 with the entry dropped... Wonder if you can take an extra check in case I miss some. -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH] devices: add support for declaring compatible matched devices
On 09/01/2023 19:58, Christian Marangi wrote: On Mon, Jan 09, 2023 at 07:53:02PM +0100, Andre Heider wrote: On 09/01/2023 19:46, Christian Marangi wrote: On Mon, Jan 09, 2023 at 07:44:34PM +0100, Andre Heider wrote: On 09/01/2023 18:28, Christian Marangi wrote: From: Jo-Philipp Wich Some device have embedded wifi card that are not connected with usb or internall with pci. Such device have fake device_id and only the vendor_id actually reflect something real but internally they don't have any id and are just matched by the node compatible binding in DT. Nice cleanup! But those fake entries in devices.txt can then be removed, right? (Assuming all of those _are_ fake and not mapped to actual pci ids) But they are dropped. Am I missing something? Everything with compatible doesn't have the id declared and internally they are all set to 0. The code that maps them to ids is dropped, the id entries mapping those to the result values are not (which is why this is so ugly ;) For the first if() that's: diff --git a/devices.txt b/devices.txt index e0663b8..040766c 100644 --- a/devices.txt +++ b/devices.txt @@ -141,7 +141,6 @@ 0x168c 0x002a 0x0777 0xe202 12 0 "Ubiquiti" "Bullet M2" 0x168c 0x002a 0x0777 0xe8055 0 "Ubiquiti" "Bullet M5" 0x168c 0x002a 0x0777 0xe3450 0 "Ubiquiti" "WispStation M5" /* ToDo: confirm offset - Wrong! */ -0x168c 0x0029 0x168c 0x91300 0 "Atheros" "AR9130" 0x168c 0x0029 0x168c 0xa0940 0 "Atheros" "AR9220" 0x168c 0x0029 0x168c 0xa0950 0 "Atheros" "AR9223" 0x168c 0x002a 0x168c 0xa0930 0 "Atheros" "AR9280" Still I'm not following... the only place we did compatible matching was in nl80211_hardware_id_from_fdt. Stuff that was present in devices.txt is all matched from pci id. Unless they are faked by some driver iwinfo in theory is using provided pci id to do the match. If that is not the case then I have no idea how iwinfo is taking the id if the connected pci card is not providing them. Happy to fix if you can give me better example but I wasn't aware we had pci device with fake id. Am I missing a patch on a different place? Drivers are not faking anything, iwinfo is. Once upon a time it only supported pci based cards, using the four id values. Later support for non-pci dt-compatible was hacked in. For that, it maps those compatible strings to made up pci ids in code, and at the same time added those fake ids to devices.txt. Like the recent commit here: https://git.openwrt.org/?p=project/iwinfo.git;a=commitdiff;h=5914d7113ecf77de63eb21fc233684d1a1a52ca5 This patch cleans that up, but it left out the device entries, which are dead now. Hope that clears it up? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH] devices: add support for declaring compatible matched devices
On Mon, Jan 09, 2023 at 07:53:02PM +0100, Andre Heider wrote: > On 09/01/2023 19:46, Christian Marangi wrote: > > On Mon, Jan 09, 2023 at 07:44:34PM +0100, Andre Heider wrote: > > > On 09/01/2023 18:28, Christian Marangi wrote: > > > > From: Jo-Philipp Wich > > > > > > > > Some device have embedded wifi card that are not connected with usb or > > > > internall with pci. Such device have fake device_id and only the > > > > vendor_id actually reflect something real but internally they don't have > > > > any id and are just matched by the node compatible binding in DT. > > > > > > Nice cleanup! But those fake entries in devices.txt can then be removed, > > > right? (Assuming all of those _are_ fake and not mapped to actual pci ids) > > > > > > > But they are dropped. Am I missing something? Everything with compatible > > doesn't have the id declared and internally they are all set to 0. > > The code that maps them to ids is dropped, the id entries mapping those to > the result values are not (which is why this is so ugly ;) > > For the first if() that's: > > diff --git a/devices.txt b/devices.txt > index e0663b8..040766c 100644 > --- a/devices.txt > +++ b/devices.txt > @@ -141,7 +141,6 @@ > 0x168c 0x002a 0x0777 0xe202 12 0 "Ubiquiti" "Bullet M2" > 0x168c 0x002a 0x0777 0xe8055 0 "Ubiquiti" "Bullet M5" > 0x168c 0x002a 0x0777 0xe3450 0 "Ubiquiti" "WispStation M5" /* > ToDo: confirm offset - Wrong! */ > -0x168c 0x0029 0x168c 0x91300 0 "Atheros" "AR9130" > 0x168c 0x0029 0x168c 0xa0940 0 "Atheros" "AR9220" > 0x168c 0x0029 0x168c 0xa0950 0 "Atheros" "AR9223" > 0x168c 0x002a 0x168c 0xa0930 0 "Atheros" "AR9280" Still I'm not following... the only place we did compatible matching was in nl80211_hardware_id_from_fdt. Stuff that was present in devices.txt is all matched from pci id. Unless they are faked by some driver iwinfo in theory is using provided pci id to do the match. If that is not the case then I have no idea how iwinfo is taking the id if the connected pci card is not providing them. Happy to fix if you can give me better example but I wasn't aware we had pci device with fake id. Am I missing a patch on a different place? -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH] devices: add support for declaring compatible matched devices
On 09/01/2023 19:46, Christian Marangi wrote: On Mon, Jan 09, 2023 at 07:44:34PM +0100, Andre Heider wrote: On 09/01/2023 18:28, Christian Marangi wrote: From: Jo-Philipp Wich Some device have embedded wifi card that are not connected with usb or internall with pci. Such device have fake device_id and only the vendor_id actually reflect something real but internally they don't have any id and are just matched by the node compatible binding in DT. Nice cleanup! But those fake entries in devices.txt can then be removed, right? (Assuming all of those _are_ fake and not mapped to actual pci ids) But they are dropped. Am I missing something? Everything with compatible doesn't have the id declared and internally they are all set to 0. The code that maps them to ids is dropped, the id entries mapping those to the result values are not (which is why this is so ugly ;) For the first if() that's: diff --git a/devices.txt b/devices.txt index e0663b8..040766c 100644 --- a/devices.txt +++ b/devices.txt @@ -141,7 +141,6 @@ 0x168c 0x002a 0x0777 0xe202 12 0 "Ubiquiti" "Bullet M2" 0x168c 0x002a 0x0777 0xe8055 0 "Ubiquiti" "Bullet M5" 0x168c 0x002a 0x0777 0xe3450 0 "Ubiquiti" "WispStation M5" /* ToDo: confirm offset - Wrong! */ -0x168c 0x0029 0x168c 0x91300 0 "Atheros" "AR9130" 0x168c 0x0029 0x168c 0xa0940 0 "Atheros" "AR9220" 0x168c 0x0029 0x168c 0xa0950 0 "Atheros" "AR9223" 0x168c 0x002a 0x168c 0xa0930 0 "Atheros" "AR9280" ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH] devices: add support for declaring compatible matched devices
On Mon, Jan 09, 2023 at 07:44:34PM +0100, Andre Heider wrote: > On 09/01/2023 18:28, Christian Marangi wrote: > > From: Jo-Philipp Wich > > > > Some device have embedded wifi card that are not connected with usb or > > internall with pci. Such device have fake device_id and only the > > vendor_id actually reflect something real but internally they don't have > > any id and are just matched by the node compatible binding in DT. > > Nice cleanup! But those fake entries in devices.txt can then be removed, > right? (Assuming all of those _are_ fake and not mapped to actual pci ids) Yes, they are all fake and actual PCI hardware with these IDs doesn't exist. Hence they should be removed. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH] devices: add support for declaring compatible matched devices
On 09/01/2023 18:28, Christian Marangi wrote: From: Jo-Philipp Wich Some device have embedded wifi card that are not connected with usb or internall with pci. Such device have fake device_id and only the vendor_id actually reflect something real but internally they don't have any id and are just matched by the node compatible binding in DT. Nice cleanup! But those fake entries in devices.txt can then be removed, right? (Assuming all of those _are_ fake and not mapped to actual pci ids) Cheers, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH] devices: add support for declaring compatible matched devices
On Mon, Jan 09, 2023 at 07:44:34PM +0100, Andre Heider wrote: > On 09/01/2023 18:28, Christian Marangi wrote: > > From: Jo-Philipp Wich > > > > Some device have embedded wifi card that are not connected with usb or > > internall with pci. Such device have fake device_id and only the > > vendor_id actually reflect something real but internally they don't have > > any id and are just matched by the node compatible binding in DT. > > Nice cleanup! But those fake entries in devices.txt can then be removed, > right? (Assuming all of those _are_ fake and not mapped to actual pci ids) > But they are dropped. Am I missing something? Everything with compatible doesn't have the id declared and internally they are all set to 0. -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH] devices: add support for declaring compatible matched devices
On Mon, 9 Jan 2023 at 18:29, Christian Marangi wrote:
>
> From: Jo-Philipp Wich
>
> Some device have embedded wifi card that are not connected with usb or
> internall with pci. Such device have fake device_id and only the
> vendor_id actually reflect something real but internally they don't have
> any id and are just matched by the node compatible binding in DT.
>
> We currently match this with a big if-else to match the single devices
> but this can be improved and be matched directly in devices.txt
>
> Rework this so that we can drop the big if-else and move the matching
> from devices.txt
>
> When a device is matched using compatible in iwinfo the hardware will be
> flagged as embedded and won't print empty ids.
>
> Tested-by: Christian Marangi
> Co-developed-by: Christian Marangi
> Signed-off-by: Jo-Philipp Wich
> Signed-off-by: Christian Marangi
Tested-by: Robert Marko
Regards,
Robert
> ---
> devices.txt | 13 +
> include/iwinfo.h | 2 ++
> iwinfo_cli.c | 9 --
> iwinfo_nl80211.c | 71 ++--
> iwinfo_utils.c | 8 +-
> 5 files changed, 36 insertions(+), 67 deletions(-)
>
> diff --git a/devices.txt b/devices.txt
> index d76bbca..93938b5 100644
> --- a/devices.txt
> +++ b/devices.txt
> @@ -206,3 +206,16 @@
> # USB devices
> # 0x | 0x | vendor id | product id | ...
> 0x 0x 0x0e8d 0x79610 0 "MediaTek" "MT7921AU"
> +
> +# FDT compatible strings
> +# "compatible" | txpower offset | frequency offset | ...
> +"qca,ar9130-wmac" 0 0 "Atheros" "AR9130"
> +"qca,ar9330-wmac" 0 0 "Atheros" "AR9330"
> +"qca,ar9340-wmac" 0 0 "Atheros" "AR9340"
> +"qca,qca9530-wmac" 0 0 "Qualcomm Atheros" "QCA9530"
> +"qca,qca9550-wmac" 0 0 "Qualcomm Atheros" "QCA9550"
> +"qca,qca9560-wmac" 0 0 "Qualcomm Atheros" "QCA9560"
> +"qcom,ipq4019-wifi" 0 0 "Qualcomm Atheros" "IPQ4019"
> +"qcom,ipq8074-wifi" 0 0 "Qualcomm Atheros" "IPQ8074"
> +"mediatek,mt7622-wmac" 0 0 "MediaTek" "MT7622"
> +"mediatek,mt7986-wmac" 0 0 "MediaTek" "MT7986"
> diff --git a/include/iwinfo.h b/include/iwinfo.h
> index e87ad18..4b63f1e 100644
> --- a/include/iwinfo.h
> +++ b/include/iwinfo.h
> @@ -243,6 +243,7 @@ struct iwinfo_hardware_id {
> uint16_t device_id;
> uint16_t subsystem_vendor_id;
> uint16_t subsystem_device_id;
> + char compatible[128];
> };
>
> struct iwinfo_hardware_entry {
> @@ -254,6 +255,7 @@ struct iwinfo_hardware_entry {
> uint16_t subsystem_device_id;
> int16_t txpower_offset;
> int16_t frequency_offset;
> + char compatible[128];
> };
>
> extern const struct iwinfo_iso3166_label IWINFO_ISO3166_NAMES[];
> diff --git a/iwinfo_cli.c b/iwinfo_cli.c
> index d70f7fb..9b3e8e3 100644
> --- a/iwinfo_cli.c
> +++ b/iwinfo_cli.c
> @@ -335,9 +335,12 @@ static char * print_hardware_id(const struct iwinfo_ops
> *iw, const char *ifname)
>
> if (!iw->hardware_id(ifname, (char *)))
> {
> - snprintf(buf, sizeof(buf), "%04X:%04X %04X:%04X",
> - ids.vendor_id, ids.device_id,
> - ids.subsystem_vendor_id, ids.subsystem_device_id);
> + if (strlen(ids.compatible) > 0)
> + snprintf(buf, sizeof(buf), "embedded");
> + else
> + snprintf(buf, sizeof(buf), "%04X:%04X %04X:%04X",
> + ids.vendor_id, ids.device_id,
> + ids.subsystem_vendor_id,
> ids.subsystem_device_id);
> }
> else
> {
> diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
> index 916192f..a9e2adf 100644
> --- a/iwinfo_nl80211.c
> +++ b/iwinfo_nl80211.c
> @@ -3445,7 +3445,7 @@ static int nl80211_get_mbssid_support(const char
> *ifname, int *buf)
>
> static int nl80211_hardware_id_from_fdt(struct iwinfo_hardware_id *id, const
> char *ifname)
> {
> - char *phy, compat[64], path[PATH_MAX];
> + char *phy, path[PATH_MAX];
>
> /* Try to determine the phy name from the given interface */
> phy = nl80211_ifname2phy(ifname);
> @@ -3453,62 +3453,10 @@ static int nl80211_hardware_id_from_fdt(struct
> iwinfo_hardware_id *id, const cha
> snprintf(path, sizeof(path),
> "/sys/class/%s/%s/device/of_node/compatible",
> phy ? "ieee80211" : "net", phy ? phy : ifname);
>
> - if (nl80211_readstr(path, compat, sizeof(compat)) <= 0)
> + if (nl80211_readstr(path, id->compatible, sizeof(id->compatible)) <=
> 0)
> return -1;
>
> - if (!strcmp(compat, "qca,ar9130-wmac")) {
> - id->vendor_id = 0x168c;
> - id->device_id = 0x0029;
> - id->subsystem_vendor_id = 0x168c;
> - id->subsystem_device_id = 0x9130;
> - } else if (!strcmp(compat, "qca,ar9330-wmac")) {
> -
[iwinfo PATCH] devices: add support for declaring compatible matched devices
From: Jo-Philipp Wich
Some device have embedded wifi card that are not connected with usb or
internall with pci. Such device have fake device_id and only the
vendor_id actually reflect something real but internally they don't have
any id and are just matched by the node compatible binding in DT.
We currently match this with a big if-else to match the single devices
but this can be improved and be matched directly in devices.txt
Rework this so that we can drop the big if-else and move the matching
from devices.txt
When a device is matched using compatible in iwinfo the hardware will be
flagged as embedded and won't print empty ids.
Tested-by: Christian Marangi
Co-developed-by: Christian Marangi
Signed-off-by: Jo-Philipp Wich
Signed-off-by: Christian Marangi
---
devices.txt | 13 +
include/iwinfo.h | 2 ++
iwinfo_cli.c | 9 --
iwinfo_nl80211.c | 71 ++--
iwinfo_utils.c | 8 +-
5 files changed, 36 insertions(+), 67 deletions(-)
diff --git a/devices.txt b/devices.txt
index d76bbca..93938b5 100644
--- a/devices.txt
+++ b/devices.txt
@@ -206,3 +206,16 @@
# USB devices
# 0x | 0x | vendor id | product id | ...
0x 0x 0x0e8d 0x79610 0 "MediaTek" "MT7921AU"
+
+# FDT compatible strings
+# "compatible" | txpower offset | frequency offset | ...
+"qca,ar9130-wmac" 0 0 "Atheros" "AR9130"
+"qca,ar9330-wmac" 0 0 "Atheros" "AR9330"
+"qca,ar9340-wmac" 0 0 "Atheros" "AR9340"
+"qca,qca9530-wmac" 0 0 "Qualcomm Atheros" "QCA9530"
+"qca,qca9550-wmac" 0 0 "Qualcomm Atheros" "QCA9550"
+"qca,qca9560-wmac" 0 0 "Qualcomm Atheros" "QCA9560"
+"qcom,ipq4019-wifi" 0 0 "Qualcomm Atheros" "IPQ4019"
+"qcom,ipq8074-wifi" 0 0 "Qualcomm Atheros" "IPQ8074"
+"mediatek,mt7622-wmac" 0 0 "MediaTek" "MT7622"
+"mediatek,mt7986-wmac" 0 0 "MediaTek" "MT7986"
diff --git a/include/iwinfo.h b/include/iwinfo.h
index e87ad18..4b63f1e 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -243,6 +243,7 @@ struct iwinfo_hardware_id {
uint16_t device_id;
uint16_t subsystem_vendor_id;
uint16_t subsystem_device_id;
+ char compatible[128];
};
struct iwinfo_hardware_entry {
@@ -254,6 +255,7 @@ struct iwinfo_hardware_entry {
uint16_t subsystem_device_id;
int16_t txpower_offset;
int16_t frequency_offset;
+ char compatible[128];
};
extern const struct iwinfo_iso3166_label IWINFO_ISO3166_NAMES[];
diff --git a/iwinfo_cli.c b/iwinfo_cli.c
index d70f7fb..9b3e8e3 100644
--- a/iwinfo_cli.c
+++ b/iwinfo_cli.c
@@ -335,9 +335,12 @@ static char * print_hardware_id(const struct iwinfo_ops
*iw, const char *ifname)
if (!iw->hardware_id(ifname, (char *)))
{
- snprintf(buf, sizeof(buf), "%04X:%04X %04X:%04X",
- ids.vendor_id, ids.device_id,
- ids.subsystem_vendor_id, ids.subsystem_device_id);
+ if (strlen(ids.compatible) > 0)
+ snprintf(buf, sizeof(buf), "embedded");
+ else
+ snprintf(buf, sizeof(buf), "%04X:%04X %04X:%04X",
+ ids.vendor_id, ids.device_id,
+ ids.subsystem_vendor_id,
ids.subsystem_device_id);
}
else
{
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index 916192f..a9e2adf 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -3445,7 +3445,7 @@ static int nl80211_get_mbssid_support(const char *ifname,
int *buf)
static int nl80211_hardware_id_from_fdt(struct iwinfo_hardware_id *id, const
char *ifname)
{
- char *phy, compat[64], path[PATH_MAX];
+ char *phy, path[PATH_MAX];
/* Try to determine the phy name from the given interface */
phy = nl80211_ifname2phy(ifname);
@@ -3453,62 +3453,10 @@ static int nl80211_hardware_id_from_fdt(struct
iwinfo_hardware_id *id, const cha
snprintf(path, sizeof(path),
"/sys/class/%s/%s/device/of_node/compatible",
phy ? "ieee80211" : "net", phy ? phy : ifname);
- if (nl80211_readstr(path, compat, sizeof(compat)) <= 0)
+ if (nl80211_readstr(path, id->compatible, sizeof(id->compatible)) <= 0)
return -1;
- if (!strcmp(compat, "qca,ar9130-wmac")) {
- id->vendor_id = 0x168c;
- id->device_id = 0x0029;
- id->subsystem_vendor_id = 0x168c;
- id->subsystem_device_id = 0x9130;
- } else if (!strcmp(compat, "qca,ar9330-wmac")) {
- id->vendor_id = 0x168c;
- id->device_id = 0x0030;
- id->subsystem_vendor_id = 0x168c;
- id->subsystem_device_id = 0x9330;
- } else if (!strcmp(compat, "qca,ar9340-wmac")) {
- id->vendor_id = 0x168c;
- id->device_id = 0x0030;
-
Re: [PATCH v2 6/7] coreutils: Import from packages feed
Petr Štetiar [2023-01-09 11:50:37]:
Hi,
> BTW ucode has `b64dec()`[1] so perhaps another viable option.
>
> 1. https://github.com/jow-/ucode#663-b64decstr
wanted to refresh my ucode brain cells, so I've explored feasibility of that
suggestion and it seems to work just fine:
#!/usr/bin/ucode
import { stdin, open, error } from 'fs';
if (length(ARGV) == 0 && stdin.isatty()) {
warn("usage: b64decode [stdin|path]\n");
exit(1);
}
let fp = stdin;
let source = ARGV[0];
if (source) {
fp = open(source);
if (!fp) {
warn(`b64decode: unable to open ${source}:
${error()}\n`);
exit(1);
}
}
print(b64dec(fp.read("all")));
fp.close();
exit(0);
BTW it needs recent ucode with fs.stdin.isatty() support[1].
Thanks Jo for helping me making above script more idiomatic. IMO it looks more
human readable, portable and maintanable then that awk based solution.
1. https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] hostapd: add support for unicast beacons
Also refresh patches.
Upstream status:
https://patchwork.ozlabs.org/project/hostap/patch/20230105200945.761324-1-raphael.melo...@mind.be/
Signed-off-by: Raphaël Mélotte
---
.../620-add-support-for-unicast-beacons.patch | 70 +++
.../hostapd/patches/700-wifi-reload.patch | 2 +-
.../patches/720-iface_max_num_sta.patch | 2 +-
...750-qos_map_set_without_interworking.patch | 2 +-
4 files changed, 73 insertions(+), 3 deletions(-)
create mode 100644
package/network/services/hostapd/patches/620-add-support-for-unicast-beacons.patch
diff --git
a/package/network/services/hostapd/patches/620-add-support-for-unicast-beacons.patch
b/package/network/services/hostapd/patches/620-add-support-for-unicast-beacons.patch
new file mode 100644
index 00..c465b5d577
--- /dev/null
+++
b/package/network/services/hostapd/patches/620-add-support-for-unicast-beacons.patch
@@ -0,0 +1,70 @@
+--- a/hostapd/config_file.c
b/hostapd/config_file.c
+@@ -3399,6 +3399,12 @@ static int hostapd_config_fill(struct ho
+ line);
+ return 1;
+ }
++ } else if (os_strcmp(buf, "beacon_da") == 0) {
++ if (hwaddr_aton(pos, bss->beacon_da)) {
++ wpa_printf(MSG_ERROR, "Line %d: invalid beacon_da item",
++ line);
++ return 1;
++ }
+ } else if (os_strcmp(buf, "use_driver_iface_addr") == 0) {
+ conf->use_driver_iface_addr = atoi(pos);
+ } else if (os_strcmp(buf, "ieee80211w") == 0) {
+--- a/hostapd/ctrl_iface.c
b/hostapd/ctrl_iface.c
+@@ -1040,6 +1040,14 @@ static int hostapd_ctrl_iface_get_config
+ return pos - buf;
+ pos += ret;
+
++ if (!is_zero_ether_addr(hapd->conf->beacon_da)) {
++ ret = os_snprintf(pos, end - pos, "beacon_da=" MACSTR "\n",
++MAC2STR(hapd->conf->beacon_da));
++ if (os_snprintf_error(end - pos, ret))
++ return pos - buf;
++ pos += ret;
++ }
++
+ #ifdef CONFIG_WPS
+ ret = os_snprintf(pos, end - pos, "wps_state=%s\n",
+ hapd->conf->wps_state == 0 ? "disabled" :
+--- a/hostapd/hostapd.conf
b/hostapd/hostapd.conf
+@@ -94,6 +94,9 @@ ssid=test
+ # UTF-8 SSID: Whether the SSID is to be interpreted using UTF-8 encoding
+ #utf8_ssid=1
+
++# Destination address for beacon frames (defaults to broadcast)
++#beacon_da=ff:ff:ff:ff:ff:ff
++
+ # Country code (ISO/IEC 3166-1). Used to set regulatory domain.
+ # Set as needed to indicate country in which device is operating.
+ # This can limit available channels and transmit power.
+--- a/src/ap/ap_config.h
b/src/ap/ap_config.h
+@@ -470,6 +470,7 @@ struct hostapd_bss_config {
+ struct hostapd_vlan *vlan;
+
+ macaddr bssid;
++ macaddr beacon_da;
+
+ /*
+* Maximum listen interval that STAs can use when associating with this
+--- a/src/ap/beacon.c
b/src/ap/beacon.c
+@@ -1595,7 +1595,12 @@ int ieee802_11_build_ap_params(struct ho
+ head->frame_control = IEEE80211_FC(WLAN_FC_TYPE_MGMT,
+ WLAN_FC_STYPE_BEACON);
+ head->duration = host_to_le16(0);
+- os_memset(head->da, 0xff, ETH_ALEN);
++ if (is_zero_ether_addr(hapd->conf->beacon_da) ||
++ is_broadcast_ether_addr(hapd->conf->beacon_da))
++ os_memset(head->da, 0xff, ETH_ALEN);
++ else {
++ os_memcpy(head->da, hapd->conf->beacon_da, ETH_ALEN);
++ }
+
+ os_memcpy(head->sa, hapd->own_addr, ETH_ALEN);
+ os_memcpy(head->bssid, hapd->own_addr, ETH_ALEN);
diff --git a/package/network/services/hostapd/patches/700-wifi-reload.patch
b/package/network/services/hostapd/patches/700-wifi-reload.patch
index 174127df6e..da9837d137 100644
--- a/package/network/services/hostapd/patches/700-wifi-reload.patch
+++ b/package/network/services/hostapd/patches/700-wifi-reload.patch
@@ -47,7 +47,7 @@
enum hostapd_logger_level logger_syslog_level, logger_stdout_level;
unsigned int logger_syslog; /* module bitfield */
-@@ -969,6 +971,7 @@ struct eht_phy_capabilities_info {
+@@ -970,6 +972,7 @@ struct eht_phy_capabilities_info {
struct hostapd_config {
struct hostapd_bss_config **bss, *last_bss;
size_t num_bss;
diff --git
a/package/network/services/hostapd/patches/720-iface_max_num_sta.patch
b/package/network/services/hostapd/patches/720-iface_max_num_sta.patch
index ed76d22dd0..e50965de06 100644
--- a/package/network/services/hostapd/patches/720-iface_max_num_sta.patch
+++ b/package/network/services/hostapd/patches/720-iface_max_num_sta.patch
@@ -71,7 +71,7 @@
" since no room for additional STA",
--- a/src/ap/ap_config.h
+++ b/src/ap/ap_config.h
-@@ -1010,6 +1010,8 @@ struct hostapd_config {
+@@ -1011,6 +1011,8 @@ struct hostapd_config {
Re: [PATCH v2 6/7] coreutils: Import from packages feed
Thibaut [2023-01-08 00:02:06]: > There might be an even easier/lighter way (short of enabling base64 in > busybox), AWK to the rescue: > https://github.com/shane-kerr/AWK-base64decode > > The code is clean and judging by the comment line 97, works with busybox awk. BTW ucode has `b64dec()`[1] so perhaps another viable option. 1. https://github.com/jow-/ucode#663-b64decstr Thibaut [2023-01-08 22:37:20]: > I wonder if it’s such a good idea to have discrepancies in busybox features > between targets? You're right, it's not a good idea. Brian Norris [2023-01-08 19:09:33]: > Thanks! That does indeed work for me. And I might just throw it into > target/linux/ipq806x/chromium/target.mk instead, since the generic > target won't be using base64. It works for me as well, but it's going to break some cases I've missed. Sorry for the noise. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
> Le 9 janv. 2023 à 04:09, Brian Norris a écrit : > > On Sun, Jan 8, 2023 at 1:37 PM Thibaut wrote: >>> Le 8 janv. 2023 à 21:53, Christian Marangi a écrit : >>> >>> On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote: […] include $(INCLUDE_DIR)/target.mk + +DEPENDS:= \ + +@BUSYBOX_DEFAULT_BASE64 + > > Thanks! That does indeed work for me. And I might just throw it into > target/linux/ipq806x/chromium/target.mk instead, since the generic > target won't be using base64. I believe that won’t work, see below. >>> Is this already used for other target? Wonder if this special thing >>> would cause some problem for packages of this target? Like discrepancy >>> with stage2 and final image? > > stage2 as in sysupgrade? I don't immediately see how that would be a > problem, but maybe I'm not understanding well enough. Packages are built on architecture-basis by a separate set of builders (« phase2 »). For ipq806x, that’s arm_cortex-a15_neon-vfpv4. While adjusting this tunable will have an effect on phase1 builds (images) and local builds from source, my understanding is it won’t affect the global architecture setting, meaning that the busybox package that’s built by the « phase2 » builders will not have this knob enabled. Thus, anyone building from imagebuilder or updating busybox from the package repo will get a version without base64, and this will break. >> AFAICT this isn’t used anywhere so far (at least according to a quick git >> grep). > > Right, I couldn't find any other target tweaking BUSYBOX_DEFAULT_* in > the current tree or in the git history. > > And I can't even find anyone doing a bare 'DEPENDS:=' in their > Makefile under target/linux/ at all. All usages are as part of > packages (modules), not device/target specifications. Most likely because of the above, which is why I’m not convinced it’s such a good idea to « set this precedent ». >>> Anyway this looks to be the best solution for the problem. >> >> I wonder if it’s such a good idea to have discrepancies in busybox features >> between targets? > > I don't think I know enough about OpenWrt development yet to have a > good answer on this, so I'll let you all try to answer this. Regardless of the above, I think these types of features (core utils that are typically used in scripts) should be enabled/disabled tree wide: otherwise, a user building a script which uses any of these features will have the « surprise » that it doesn’t work consistently on all devices, and that IMHO is bad. My 2c. T ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Aluminum die casting technology
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Good morning, we provide the technology of aluminum die casting. We have production plants located in Poland, Germany and Slovakia with the possibility of flexible shifting of production between locations. Our casting cells are mostly automatic or semi-automatic, which allows the production of large production runs with high flexibility of details in the areas from 50 to 3000g. We have been trusted by many reputable clients, including BOSH, Daimler, ZF, Rockwell Automation. We provide support at every stage of project development, we develop the structure of the detail. Would you like to talk about cooperation in this area? Regards Aidan Wallace --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
