| Message ID | 20170815104933.16705-1-zajec5@gmail.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Rafał Miłecki |
| Headers | show |
On 15 August 2017 at 12:49, Rafał Miłecki <zajec5@gmail.com> wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > Example frequency: > { > "channel": 1, > "mhz": 2412, > "restricted": false, > "active": false, > "restrictions": { > "no_ht40minus": true, > "no_80mhz": true > } > } Jo, what do you think about this? I think you got some comments on the suggested JSON format.
Hi Rafał,
in principle fine with me - but I guess all restrictions will be in the
form { <restriction>: true } so I'd rather make it an array.
Also since a restriction implies something not possible, I'd drop the
"no_" prefix too. So in the end it would look like:
{
"channel": 1,
"mhz": 2412,
"restricted": false,
"active": false,
"restrictions": [
"ht40minus",
"80mhz"
}
}
~ Jo
Hi, On 12 December 2017 at 23:05, Jo-Philipp Wich <jo@mein.io> wrote: > Hi Rafał, > > in principle fine with me - but I guess all restrictions will be in the > form { <restriction>: true } so I'd rather make it an array. > > Also since a restriction implies something not possible, I'd drop the > "no_" prefix too. So in the end it would look like: > > { > "channel": 1, > "mhz": 2412, > "restricted": false, > "active": false, > "restrictions": [ > "ht40minus", > "80mhz" > } Do these value say what the device is restricted from, or restricted to? I'd argue the no_ prefix makes it more clear that these restrictions say what is prohibited, not what is allowed. Regards Jonas
On 12 December 2017 at 23:13, Jo-Philipp Wich <jow@openwrt.org> wrote: > Hi, > >> I'd argue the no_ prefix makes it more clear that these restrictions >> say what is prohibited, not what is allowed. > > What about calling it "prohibit" instead of "restrictions" then? That > would make it both terse and unambiguous. Make it "prohibitions" (or "prohibited") and fine by me. I'm no native speaker though, so if anyone could step in if I say crap that would be helpful. Not calling it "restrictions" also avoids the awkwardness of the channel not being restricted ("restricted: false") but having restrictions, which somewhat contradicts itself on a first glance. Regards Jonas
diff --git a/iwinfo.c b/iwinfo.c index 1849196..3f18ae2 100644 --- a/iwinfo.c +++ b/iwinfo.c @@ -503,7 +503,7 @@ rpc_iwinfo_freqlist(struct ubus_context *ctx, struct ubus_object *obj, int i, rv, len, ch; char res[IWINFO_BUFSIZE]; struct iwinfo_freqlist_entry *f; - void *c, *d; + void *c, *d, *e; rv = rpc_iwinfo_open(msg); @@ -531,6 +531,21 @@ rpc_iwinfo_freqlist(struct ubus_context *ctx, struct ubus_object *obj, if (ch > -1) blobmsg_add_u8(&buf, "active", f->channel == ch); + e = blobmsg_open_table(&buf, "restrictions"); + if (f->flags & IWINFO_FREQ_NO_10MHZ) + blobmsg_add_u8(&buf, "no_10mhz", 1); + if (f->flags & IWINFO_FREQ_NO_20MHZ) + blobmsg_add_u8(&buf, "no_20mhz", 1); + if (f->flags & IWINFO_FREQ_NO_HT40PLUS) + blobmsg_add_u8(&buf, "no_ht40plus", 1); + if (f->flags & IWINFO_FREQ_NO_HT40MINUS) + blobmsg_add_u8(&buf, "no_ht40minus", 1); + if (f->flags & IWINFO_FREQ_NO_80MHZ) + blobmsg_add_u8(&buf, "no_80mhz", 1); + if (f->flags & IWINFO_FREQ_NO_160MHZ) + blobmsg_add_u8(&buf, "no_160mhz", 1); + blobmsg_close_table(&buf, e); + blobmsg_close_table(&buf, d); } }