Re: [PATCH 11/20] [WIP] package/target: update to get modules from $(LINUX_OBJ_DIR)
On Sat, Nov 11, 2023 at 10:51:08PM -0800, Elliott Mitchell wrote: > Modules built from kernel source will now be in $(LINUX_OBJ_DIR). > > Signed-off-by: Elliott Mitchell > --- > package/kernel/linux/modules/block.mk| 106 +++ > package/kernel/linux/modules/can.mk | 36 +-- > package/kernel/linux/modules/crypto.mk | 252 > package/kernel/linux/modules/firewire.mk | 8 +- > package/kernel/linux/modules/fs.mk | 100 +++ > package/kernel/linux/modules/gpio-cascade.mk | 2 +- > package/kernel/linux/modules/hwmon.mk| 98 +++ > package/kernel/linux/modules/i2c.mk | 2 +- > package/kernel/linux/modules/iio.mk | 80 +++--- > package/kernel/linux/modules/input.mk| 26 +- > package/kernel/linux/modules/leds.mk | 20 +- > package/kernel/linux/modules/lib.mk | 76 ++--- > package/kernel/linux/modules/multiplexer.mk | 4 +- > package/kernel/linux/modules/netdevices.mk | 214 +++--- > package/kernel/linux/modules/netfilter.mk| 168 +-- > package/kernel/linux/modules/netsupport.mk | 204 ++--- > package/kernel/linux/modules/nls.mk | 44 +-- > package/kernel/linux/modules/other.mk| 202 ++--- > package/kernel/linux/modules/pcmcia.mk | 14 +- > package/kernel/linux/modules/sound.mk| 98 +++ > package/kernel/linux/modules/spi.mk | 10 +- > package/kernel/linux/modules/usb.mk | 288 +-- > package/kernel/linux/modules/video.mk| 168 +-- > package/kernel/linux/modules/virt.mk | 24 +- > package/kernel/linux/modules/w1.mk | 2 +- > package/kernel/linux/modules/wpan.mk | 20 +- > target/linux/apm821xx/modules.mk | 4 +- > target/linux/armsr/modules.mk| 80 +++--- > target/linux/at91/modules.mk | 18 +- > target/linux/ath79/modules.mk| 2 +- > target/linux/bcm27xx/modules/hwmon.mk| 2 +- > target/linux/bcm27xx/modules/other.mk| 6 +- > target/linux/bcm27xx/modules/sound.mk| 206 ++--- > target/linux/bcm27xx/modules/spi.mk | 4 +- > target/linux/bcm27xx/modules/video.mk| 16 +- > target/linux/bcm47xx/modules.mk | 6 +- > target/linux/bcm53xx/modules.mk | 6 +- > target/linux/bcm63xx/modules.mk | 4 +- > target/linux/bmips/modules.mk| 6 +- > target/linux/gemini/modules.mk | 2 +- > target/linux/ipq806x/modules.mk | 14 +- > target/linux/kirkwood/modules.mk | 4 +- > target/linux/layerscape/modules.mk | 4 +- > target/linux/mediatek/modules.mk | 8 +- > target/linux/mvebu/modules.mk| 4 +- > target/linux/oxnas/modules.mk| 4 +- > target/linux/ramips/modules.mk | 20 +- > target/linux/sunxi/modules.mk| 16 +- > target/linux/x86/modules.mk | 22 +- > 49 files changed, 1362 insertions(+), 1362 deletions(-) The reason this patch ended up so huge was every kernel module package was setting $(FILES) to the absolute path of the module. If instead $(FILES) is set relative to the kernel object directory, and converted to an absolute path during KernelPackage/$(1)/config, this becomes MUCH smaller. Unfortunately in turn the patch to do that ends up jumbo. Can't win. The cleanup has been long needed, but never done. Now it ends up a gigantic patch. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 07/20] kernel: copy all built kernel modules to root filesystem image
On Sat, Nov 18, 2023 at 07:57:35AM +0100, Felix Fietkau wrote: > On 17.11.23 22:31, Elliott Mitchell wrote: > > On Fri, Nov 17, 2023 at 05:20:33PM +0100, Felix Fietkau wrote: > >> On 11.11.23 01:21, Elliott Mitchell wrote: > >> > This removes the requirement for to create a package for all modules. > >> > Now devices can simply specify in-tree drivers/other to be built as > >> > modules and they will be present in the resultant image. > >> > > >> > Signed-off-by: Elliott Mitchell > >> > >> It seems to me that this completely ignores the use case of having > >> release builds that ship a lot of kernel modules as installable > >> packages. Did I misread something? > >> If not, this gets a strong NACK from me. > > > > Should be completely orthogonal, though it could have bugs. > > > > Using `cp -l` has two valuable effects: First, it reduces storage space > > usage. Second, it serves to mark module files as belonging to a package. > > > > My goal is previously setting a kernel option to "m" in a configuration > > file, but not having a package causes it to be built, then ignored. I > > want this to do something sensible, not simply waste electricity > > building a module and then tossing it in the garbage. > > > > Hmm, come to think of it, that should be $(XARGS) (fix on commit?). > > Thanks for the explanation, it makes more sense to me now. > That said, I see a few pitfalls here: > > 1. If you select kernel modules that depend on other modules selected > via kmod packages, you end up with non-functional modules with missing > dependencies in the rootfs. Is this actually that much of a problem? From what I've seen most kmod packages handled during image build get preinstalled onto the root fs image. As such these would nominally function as long as the packages weren't removed. Wouldn't this also indicate breakage in the module package anyway? > 2. If the kmod package selection accidentally ends up selecting extra > modules that aren't stored in the package, you end up with rootfs bloat. Eww, that would be gross. As with the above, wouldn't this be indicating breakage in the module packaging anyway? > I'm fine with the cp -l change, but I think adding all remaining modules > to the rootfs is not something we should do by default (maybe opt-in?) Perhaps. This could also be handled by the approach the series as a whole is aiming for. If kernel module building used a separate object directory from the kernel build, then modules selected in the device configuration could be isolated. > By the way, I still get bounces when replying to you, because your mail > server is refusing my mail. Ick. Welcome to the world of 2023 and what spam has done to e-mail. Alas, this is due to extreme measures being taken by the person who handles this system. We're at a point where small mailservers cannot exist due to the shear amount of spam being generated. I suppose OpenWRT might help by having a default rule to filter out port 25. There is also that yet to be written kernel patch which disables the interfering 2.45GHz channels. There is also the default egress filtering... All those things I could get done if I ruled the world. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[sdwalker/sdwalker.github.io] 7df39f: This week's update
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 7df39f1e18b624aa23b9ae4fe3514ea035dcc72d https://github.com/sdwalker/sdwalker.github.io/commit/7df39f1e18b624aa23b9ae4fe3514ea035dcc72d Author: Stephen Walker Date: 2023-11-19 (Sun, 19 Nov 2023) Changed paths: M uscan/index-22.03.html M uscan/index-23.05.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] kernel: usb: Autoprobe g_serial
Hi Linus, W dniu 2023-11-11 o 23:02, Linus Walleij pisze: For devices using USB gadget serial we need to probe the modules usb_f_acm and g_serial in order, then the available UDC (USB device controller) interface will be hooked up to a serial port as /dev/ttyGS0. (On the host side this appears as /dev/ttyACM0 when plugging in the USB cable.) I don't quite understand why this wasn't done before for the module explicitly called kmod-usb-serial. Before this patch we have to enter a console and type modprobe g_serial To get a serial console on /dev/ttyGS0, after this it is automatic. Since you might only have the serial console, it is a bit catch 22 to have to use a serial console to activate the serial console. Signed-off-by: Linus Walleij --- package/kernel/linux/modules/usb.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/linux/modules/usb.mk b/package/kernel/linux/modules/usb.mk index 0a5f5a8993c9..f54dc4380737 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -207,7 +207,7 @@ define KernelPackage/usb-gadget-serial $(LINUX_DIR)/drivers/usb/gadget/function/usb_f_obex.ko \ $(LINUX_DIR)/drivers/usb/gadget/function/usb_f_serial.ko \ $(LINUX_DIR)/drivers/usb/gadget/legacy/g_serial.ko - AUTOLOAD:=$(call AutoLoad,52,usb_f_acm) + AUTOLOAD:=$(call AutoLoad,52,usb_f_acm g_serial) $(call AddDepends/usb) endef I think I know the reason why it isn't the case. kmod-usb-gadget-cdc-composite which pulls both kmod-usb-gadget-serial and kmod-usb-gadget-eth packages, and including autoprobingf g_serial within this would clash with that. I think the gadget configuration itself (apart from implementation) could be packaged separately and included as device packages, pulling needed dependencies. And something like that just appeared on Github: https://github.com/openwrt/openwrt/pull/14005/ -- Pozdrawiam/Kind regards, Lech ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] kernel: usb: Autoprobe g_serial
Hi! On Sun, Nov 12, 2023 at 6:04 AM Linus Walleij wrote: > > For devices using USB gadget serial we need to probe the modules > usb_f_acm and g_serial in order, then the available UDC (USB device > controller) interface will be hooked up to a serial port as > /dev/ttyGS0. (On the host side this appears as /dev/ttyACM0 > when plugging in the USB cable.) > > I don't quite understand why this wasn't done before for the > module explicitly called kmod-usb-serial. The g_*.ko gadget modules conflict with each other. I think it isn't loaded by default to prevent that when users decided to install multiple of them. I made an init script to setup USB gadget using the "modern" configfs approach: https://github.com/openwrt/openwrt/pull/14005 Maybe you can make use of this one instead? :) -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
