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? 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. 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. 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. So, I find the build system very limiting and problematical, but that doesn't mean that I've been hacking around it - the only changes are those that I've published plus the addition of one additional kernel patch file. -- 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
