<dwfreed>
rather than ping them, lead with your real question
<dwfreed>
so when they are around, they can just give an answer if they can, or ask a real followup question, rather than having to ask wtf you wanted :P
<hitech95>
To mee it seems that it is used to always have a failback net device to set as primary if by mistake someone remove the primary one from the bond.
nixuser has quit [Read error: Connection reset by peer]
nixuser has joined #openwrt-devel
<hitech95>
So my plan to fix this would be: correctly set the set_primary for each port of the list, but then when you set the port status in the bond I use the primary_port reference to evaluate if the port must be set as primary or not.
<hitech95>
I'm not sure if this si the indendeb behaviour as the bonding_reset_primary is called after the calls to bonding_enable_port
dermoth_ has joined #openwrt-devel
dermoth has quit [Remote host closed the connection]
dermoth_ is now known as dermoth
Tapper has joined #openwrt-devel
plappermaul has joined #openwrt-devel
ScrewDri- has joined #openwrt-devel
ScrewDriver1337 has quit [Ping timeout: 480 seconds]
ScrewDri- is now known as ScrewDriver1337
ScrewDri- has joined #openwrt-devel
ScrewDriver1337 has quit [Ping timeout: 480 seconds]
Forst has quit [Read error: Connection reset by peer]
Forst has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
<Rondom>
Does anyone have any code examples or best practices for creating back pressure with uloop?
<Rondom>
I am encountering a problem where continuous input can hog the event loop because the callback is not yielding control back to the loop but will just continuously read.
<Rondom>
Specifically, this is a problem inside procd when it captures stdout/err
goliath has joined #openwrt-devel
<hitech95>
russell--, nop, unfortunately it try to download the packages via the network even if I have copied it. I suppose it is due to the fact that it uninstall the network daemon and it cannot resolve/open the connections to do the opkg update or something.