Re: [LEDE-DEV] [PATCH v2 2/5] mac80211: use uci to generate wireless config file

[Christian Lamparter]

On Wednesday, October 12, 2016 2:05:15 PM CEST Matthias Schiffer wrote:
> On 10/12/2016 01:42 PM, Jonas Gorski wrote:
> > On 11 October 2016 at 13:37, Christian Lamparter
> >  wrote:
> >> Previously, wifi detect simply dumped its generated wireless
> >> configuration out to STDOUT. A second step was needed to
> >> append the configuration to /etc/config/wireless (or create
> >> it, if it didn't exist).
> >>
> >> With this patch, The wifi detection script will now use uci
> >> to update the wireless configuration directly.
> >>
> >> Note: uci writes a "cfg123456" printout to stdout when it
> >> generates a name for the unnamed section ("add wireless wifi-iface").
> > 
> > This rather sounds like a bug in uci, at least I would expect it to
> > generate no output if it is invoked with "-q", neither on stdout nor
> > stderr.
There's a description in uci's list.c [0] that states the purpose of the
printout.

"[...] This is used as reference when locating or updating the section
from apps/scripts. To make multiple concurrent versions somewhat safe
for updating, the name is generated from a hash of its type and name/value
pairs of its option, and it is prefixed by a counter value. If the order
of the unnamed sections changes for some reason, updates to them will be
rejected."

The cfg123456 string produced by the fprintf(stdout, ...) in uci_do_add [1].

> >> Since we currently pipe wifi detect into /etc/config/wireless, we
> >> have to redirected this output, so it doesn't end up in the wireless
> >> configuration file.
> > 
> > I wonder if it wouldn't be better to keep "detect" output to stdout,
> > and add a new command that modifies the uci config (e.g. "update" or
> > "refresh"). People might rely/expect the current behavior, and get
> > confused when it stops working.
> >
> Maybe we could just rename wifi-detect to something different, so nobody
> would expect the old behaviour? Keeping two separate code paths doesn't
> seem like a good idea to me.
I renamed it to "wifi config" for now. I've played around with making a
"compat" 'wifi detect' that simply prints the current config to stdout. 

i.e.:
wifi_detect() {
   wifi_config &> /dev/null

   tmp=$(mktemp -u); cp /etc/config/wireless "$tmp"; cat "$tmp"; rm -f 
"$tmp"
}

this will work for wifi detect > /etc/config/wireless. But it also will cause
to spawn duplicates if ">>" is used.

Any clever ideas? Otherwise, I can drop the uci changes. They are certainly nice
to have, but we can manage without them.

Regards,
Christian
---

[0] 


[1] 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2 2/5] mac80211: use uci to generate wireless config file

[Matthias Schiffer]

On 10/12/2016 01:42 PM, Jonas Gorski wrote:
> On 11 October 2016 at 13:37, Christian Lamparter
>  wrote:
>> Previously, wifi detect simply dumped its generated wireless
>> configuration out to STDOUT. A second step was needed to
>> append the configuration to /etc/config/wireless (or create
>> it, if it didn't exist).
>>
>> With this patch, The wifi detection script will now use uci
>> to update the wireless configuration directly.
>>
>> Note: uci writes a "cfg123456" printout to stdout when it
>> generates a name for the unnamed section ("add wireless wifi-iface").
> 
> This rather sounds like a bug in uci, at least I would expect it to
> generate no output if it is invoked with "-q", neither on stdout nor
> stderr.
> 
>> Since we currently pipe wifi detect into /etc/config/wireless, we
>> have to redirected this output, so it doesn't end up in the wireless
>> configuration file.
> 
> I wonder if it wouldn't be better to keep "detect" output to stdout,
> and add a new command that modifies the uci config (e.g. "update" or
> "refresh"). People might rely/expect the current behavior, and get
> confused when it stops working.
> 
> 
> Jonas
> 

Maybe we could just rename wifi-detect to something different, so nobody
would expect the old behaviour? Keeping two separate code paths doesn't
seem like a good idea to me.

Regards,
Matthias



signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev