On Wed, 27 Nov 2019 at 14:27, Russell King - ARM Linux admin <li...@armlinux.org.uk> wrote: > > On Wed, Nov 27, 2019 at 02:03:40PM +0100, Jonas Gorski wrote: > > On Wed, 27 Nov 2019 at 13:14, Russell King - ARM Linux admin > > <li...@armlinux.org.uk> wrote: > > > > > > On Wed, Nov 27, 2019 at 12:57:35PM +0100, Petr Štetiar wrote: > > > > Russell King - ARM Linux admin <li...@armlinux.org.uk> [2019-11-27 > > > > 10:35:10]: > > > > > > > > > It makes it very difficult to understand. For example, where is the > > > > > kernel + kmod package version/release set > > > > > > > > from > > > > kmod-libphy_4.19.85-1_aarch64_cortex-a53.ipk/control.tar.gz/control: > > > > > > > > Package: kmod-libphy > > > > Version: 4.19.85-1 > > > > Depends: kernel (=4.19.85-1-f24e301be88eb921523d0eb26012ec0f) > > > > > > > > I'm interested how the Version: is set: > > > > > > > > $ git grep Version: include/ > > > > include/package-dumpinfo.mk:)Version: $(VERSION) > > > > > > > > So then I need to know how the VERSION is set: > > > > > > > > $ git grep VERSION.*:.*= include/kernel* > > > > include/kernel.mk: VERSION:=$(LINUX_VERSION)$(if > > > > $(PKG_VERSION),+$(PKG_VERSION))-$(if > > > > $(PKG_RELEASE),$(PKG_RELEASE),$(LINUX_RELEASE)) > > > > > > > > So from above it's PKG_RELEASE or LINUX_RELEASE now: > > > > > > > > $ git grep -E '(PKG_RELEASE|LINUX_RELEASE)' include/kernel* > > > > include/kernel-version.mk:LINUX_RELEASE?=1 > > > > > > > > So in order to bump the release in the 4.19.85-1 from 1 to 2 I would > > > > probably > > > > need to set LINUX_RELEASE:=2 somewhere in the Make files or provide it > > > > to Make > > > > via commandline, as `make ... LINUX_RELEASE=2`. > > > > > > Thanks, that's useful information. > > > > To add to this, the f24e301be88eb921523d0eb26012ec0f part is the hash > > of the kernel config used during the build of the module/kernel. This > > is to avoid installing kernel modules build with a different ABI due > > to different config. > > > > See > > https://github.com/openwrt/openwrt/blob/master/include/kernel-defaults.mk#L108 > > for how it's generated. > > > > > > > > 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? > > > > > > > > I'm not implying that, but Jonas is already involved and has access to > > > > the > > > > actual hardware, so it makes sense to let him test and merge it. > > > > > > Hmm, so you're saying that the mainline kernel maintainer (me) > > > shouldn't be pushing these patches for OpenWrt, because you don't > > > trust me to test them, despite testing them on the uDPU, SolidRun > > > Clearfog and cex7 platforms with multiple different SFP and SFP+ > > > modules from several vendors. > > > > > > Instead you'd rather trust someone with only one SFP module, who's > > > patch that was merged into OpenWrt will break some modules that > > > have been tested to work with the upstream kernel? > > > > > > Sound sane? > > > > > > I think you're actually confused about what I've asked Jonas to do. > > > I haven't asked him to test these patches with a view to merging > > > them, I've asked him to report back what the situation is with this > > > patch set without his "450-reprobe_sfp_phy" patch applied, which > > > never made it into the upstream kernel - and then we'll work on a > > > way to make his module work with *both* OpenWrt and the mainline > > > kernel. > > > > The bit you are probably missing is that I also happen to be an > > OpenWrt maintainer with commit access. > > > > So unless you also have commit access yourself you would need someone > > from the maintainer group to accept and merge your patches. And since > > I have access to a device with an SFP port, I can do both the checks > > you asked me to do as well as do the merge. Two birds with one stone > > ;-) > > > > And sometimes changes can have unexpected side effects due to the > > amount of local patches we have for each target, and I don't expect > > anyone to be aware of all of them, or having tested all of them. > > Well, I expect your testing to fail, because your module is likely > non-compliant in regard of holding the TX_FAULT signal active while > it is initialising - but then most copper modules behave the same > way, just for a shorter time. > > Given that your testing won't be successful, what do we do?
The testing doesn't need to succeed to be successful, it just needs to not break anything else (in a obvious way). I probably see that it still tries to detect the problematic SFP module (and then fail to probe the PHY), test a few others that hopefully do work (I can borrow some other modules from work), maybe check one or two other 4.19 based targets to do a simple check for any side effects to other targets, then merge it. > Or are you proposing just a compile test? > > > I hope that clears it a bit up? Nothing about not trusting you and > > your code, just not trusting it blindly. Especially since you > > mentioned having issues with the OpenWrt build system. > > The build system is just very painful for a new-comer to understand. > I don't doubt that it does what you need it to, but trying to work > out stuff from it is a nightmare unless you have some knowledge > about how it is setup. > > For example, referencing: > > https://openwrt.org/docs/guide-developer/single.package > > and trying to build just the kernel. So: > > $ make tools/install > $ make toolchain/install > $ make target/linux/install > > fails because there is no opkg host tool present. Congratulations, you found a bug! Looks like there is a missing dependency in the build system. Feel free to report it [1]. I might take a look at it regardless. But there also is a systemic issue that there is no separate "compile the kernel" build target, and it's mixed with the "assemble the rootfs and images" step - which then requires opkg (and everything else). So in all likelihood even with the dependency fixed it would have then tried to build everything anyway, as target/linux/install is one of the last steps in the build process. > > Trying to find out how to build opkg is really not easy. You find > "host-compile" and "host-install" targets in the makefiles, so you > assume that if you try make package/system/opkg/host-install, maybe > it'll install a host built opkg into staging_dir/host/bin - but no, > that doesn't work. That seems to be utterly impossible to do. > That has alone made me develop a great hate for the implementation > after spending a lot of time trying to figure it out. I can understand that frustration, good documentation is hard to come by. For me most of these things are "obvious" and "easy" since I'm working since decades with it, but a lot of it is not really well documented, or even at all. > > The only way seems to be to use plain "make" in the top level > directory - so the information in the above URL is plainly > misleading. If you haven't been through the entire configuration > in 'make menuconfig' before, you end up having to build an entire > OpenWrt system - which really isn't nice if you're either limited > with disk space or on a 'net connection with a limited monthly > allowance. I can also understand this frustration. I don't know it it helps in the future, but there is a "make download" command to make it just download everything, which might be helpful if you can pre-download everything at work/mc-donalds/whereever you don't have a metered connection, and then do the build later at home where you are limited by the monthly allowance. Best regards, Jonas _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
