W dniu 06.03.2019 o 20:44, Tomasz Maciej Nowak pisze: > W dniu 04.03.2019 o 20:52, Petr Štetiar pisze: >> Tomasz Maciej Nowak <tome...@o2.pl> [2019-03-04 19:25:12]: >> >>>>> [ -f "$CONF_TAR" -a "$SAVE_CONFIG" -eq 1 ] && append="-j >>>>> $CONF_TAR" >>>>> dd if="$sysup_file" bs=64k skip=1 2>/dev/null | \ >>>>> - mtd -r $append -Fkernel:$kern_length:0x80060000,rootfs >>>>> write - kernel:rootfs >>>>> + mtd -r $append >>>>> -F$CI_KERNPART:$kern_length:0x80060000,rootfs write - $KERNPART:rootfs >>>> >>>> instead of passing CI_KERNPART as global variable, wouldn't it be better to >>>> pass CI_KERNPART as 2nd argument to this function? Something like this: >>> >>> I just followed an example like in: >>> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq40xx/base-files/lib/upgrade/platform.sh >>> this is how all other targets pass additional options. Changing this is >>> possible, but I would like to keep it consistent with other implementations. >> >> I think, that's this isn't exactly good example to follow, but I can see why >> it's done this way, just take a look at >> package/base-files/files/lib/upgrade/nand.sh >> >> You don't need to try shoot yourself into the foot :-) >> > > Thanks for pointing that out, I overlooked what was included in the script i > pointed to. Version 2 sent. > >>>>> + /* Didn't find it */ >>>>> ++ if (offset + master->erasesize < master->size) { >>>>> ++ /* not at the end of the flash yet, maybe next >>>>> block :) */ >>>>> ++ directory++; >>>>> ++ goto restart; >>>>> ++ } >>>> >>>> I'm wondering if this patch could be upstreamed first, so we don't need to >>>> drag it around forever. >>> >>> Yes, that would be preferred, but given my lack of skills and understanding >>> in that regard (no programming skills), I don't see that accepted. >> >> I would say, that patch is either good enough for upstream, or it has to have >> very good reason to be included and maintained in OpenWrt. So, why does this >> patch belong to OpenWrt if it might not be good enough for upstream? >> > > Would like also to know this, I can assume, since there is option on which > block to look for FIS table, available in kernel config, there shouldn't be > necessity for this patch. The problem is when one wants to support more > boards with same kernel, but those have partition in different place. Anyway, > maybe someone from core OpenWrt devs could shed som light on this? > > Regarding the part: "I don't see that accepted", I meant if there would be > request to change the patch it would be something like this: "Ekh... hmm... > how would I do that, don't know any programming.". So I would that patch > would stuck in limbo.
My typing is failing, last sentence should be: So that patch would stuck in limbo. > >> BTW, if you're able to submit patches in this very good quality to OpenWrt, >> I'm pretty sure, that you can do this for kernel as well :-) > > Sending patches to OpenWrt is easy :) > >> >> -- ynezz >> > > Regards > -- TMN _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
