On Wed, Nov 27, 2019 at 10:35:10AM +0000, Russell King - ARM Linux admin wrote: > On Wed, Nov 27, 2019 at 09:50:45AM +0100, Petr Štetiar wrote: > > Russell King - ARM Linux admin <li...@armlinux.org.uk> [2019-11-26 > > 00:07:43]: > > > > Hi, > > > > > I can see your reply in the OpenWrt archives, but I never received > > > it, so I can't reply to it... (I'm not subscribed to openwrt-devel.) > > > > FYI René just didn't Cc: you. > > Yes, I guessed as much, as some mailing lists are switching to a "reply > to list" policy - which is fine if you can guarantee that all who post > there are subscribed. With an open list, you end up with exactly this > problem. > > > > My impression is that the build system is designed to keep people out! > > > > You mean Make was designed to keep people out? :-) > > > > Puting jokes aside, if you imagine, that OpenWrt provides complete flashable > > images (bootloader, kernel, modules, firmware, userspace, web UI), packages > > with package manager, package feeds, SDK, image builder and all of this for > > insane number of platforms and devices. Then add Linux/macOS/WSL host build > > systems in the mix and you'll end up with pretty complex prerequisites. > > It makes it very difficult to understand. For example, where is the > kernel + kmod package version/release set - and should it be > incremented so that opkg on the target doesn't mess up it's "status" > file when reinstalling the kmod packages? (Yes, I've had to manually > edit that file to get rid of any entry with "install ok not-installed" > status, because opkg won't do _anything_ with those. > > > > Some guidance would be most helpful. Silence on the other hand > > > will result in nothing changing. > > > > AFAIK Jonas plans to borrow few SFP modules and test this on his ClearFog > > PRO > > and he is eventually going to merge this as well. > > Surely only one person should be merging this? > > > > 1) as these are touching phy code, using 7xx numbers would be > > > reasonable Or maybe 0xx for at least some? > > > > It's just a soft guidance, not pedantic system, I mean if you look at mvebu > > patches, you can see net/phy related patches with 5xx numbering scheme. > > Sometimes it's being done on purpose, in order to make refreshing of patches > > easier and/or to avoid clashes with some other patches. > > > > If you take a look in include/quilt.mk you'll find out following: > > > > $(call PatchDir,$(LINUX_DIR),$(GENERIC_BACKPORT_DIR),generic-backport/) > > $(call PatchDir,$(LINUX_DIR),$(GENERIC_PATCH_DIR),generic/) > > $(call PatchDir,$(LINUX_DIR),$(GENERIC_HACK_DIR),generic-hack/) > > $(call PatchDir,$(LINUX_DIR),$(PATCH_DIR),platform/) > > > > which means, that the resulting kernel is being constructed from > > generic/backport, generic/pending, generic/hack, generic/files, > > platfrom/patches and platform/files sources. > > > > So when you're adding something it's good to keep this in mind in order to > > avoid possible clashes. I would probably just stick with 7xx. > > Ok. > > > > 2) there are no 7xx numbers in target/linux/generic/backport-4.19, so > > > numbering them 700 through to 742 for the first patches would be > > > okay? These are all queued in mainline net-next. > > > > Yes. FYI in order to make the kernel refresh process easier/obvious, it's > > nice > > to have (not mandatory) the kernel version at the beginning of the filename. > > Ok. I've needed to move some additional patches from mvebu to generic > for this. > > > > 3) patch 3 aren't queued yet, but are published in my git tree, and will > > > be sent for the next merge window. Does this still qualify as > > > suitable for backport-4.19, or should they go elsewhere? > > > > From my POV it's backport. > > Ok. > > > > 4) patch 4, the uDPU patches stay in target/linux/mvebu/patches-4.19? > > > > Yes. > > Ok. > > > > 3xx or some other number? > > > > 0xx or 3xx, usually whatever avoids clashes with any previous/later patches > > :-) > > I've ended up giving them 544..546 to follow on from the last DTS patch. > Looking at the numbering used there, there doesn't seem to be any rhyme > or reason to it. > > > > 5) the final patch, which isn't in mainline, and probably needs further > > > work - should that go in target/linux/generic/hack-4.19 ? > > > > If you're talking here about 1/4, then this one is probably just fine as it > > is. > > I'm talking about 4/4, the "work around Nokia GPON module's TX_FAULT > assertion" patch.
Sorry, looks like I never sent that one (which would've been patch 5!) > > > What about the numbering of the existing 7xx patches there - do I just > > > pick > > > the first available 7xx number, i.o.w. 701 ? > > > > Yes. > > Thanks, your reply has allowed me to proceed with some confidence that > I'm doing the correct thing. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up > According to speedtest.net: 11.9Mbps down 500kbps up -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
