From nobody Thu Jan 18 21:35:43 2024 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TGGJL1gBgz573X1; Thu, 18 Jan 2024 21:35:46 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TGGJK6Xtyz4mbJ; Thu, 18 Jan 2024 21:35:45 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705613745; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=J7VT2fbyC2ibwMh/iMZvAsCHOdKyRWaUOIn+cO7bVm0=; b=InWY/6qgjXeWIyJbz/qWyu77CQJiCV09/q7gAy92fpMHZrtQ+IieIwV9q/EZ0AAZIBdYTR fwNGeDt/QHBWcW2uue+EEidcs5RyrOHjDBgHPVSFZsJ/x19O9HZ0hPr/WNe4T0pRmeJwsS FBPAjW5Wm9J4NXB/lLovg0Ex09tGtOmn5zEfz2Mzhl+HjjwXBzMG3aNKlbyywMVgtDXLyt rMUJoVdYncdPcxJMKlNqM05aZkkiRL/joDZ96yUtCU+3bfvSJFiMoWUCNCGUQukwYWCIq3 u1pgIlFq2chEQtj0XX4gN0+deVvyFRgEM/he1DAfH0pXxOM1sabTv2E0mW1LLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705613745; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=J7VT2fbyC2ibwMh/iMZvAsCHOdKyRWaUOIn+cO7bVm0=; b=cCmacYZI97yhr9KObi19kjefLl2w5s6cV+fddQ5IlJjq+RWCC4JjyvIAu/8b8bXU4BznsD OCK5vHF6NPfJknVMV282hh5wbobLmsEejkcOkbmGMerdQl11DdE/N0tRlZYUtlbn8SIXb4 X0/bsBnh6xUBYGW0ko++Q4m2TPucigHPxmYVA/U89BiJpnXPsRQBOKRGEUw6jaY0mI/gy3 I/j0RVuTF90V+V/aXzEqUo0fR1McZ/iiRjLx9PCLi9ih5KzyusbWrlYanrSEYwHQ0DLDjd NdrmuFatMoKm7RJzH3USVfHPgsXVVFcQc5suJjkGrFbXKIVSQhbQfdeAnRI6Tw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705613745; a=rsa-sha256; cv=none; b=LJCxJW7S9Wd5aH/ZJHJqciiuxvncE6kI66eOVcNg6Ye1qQKBnQ5z6MWF9SiyAgaDhRejd2 xjVV3oa0MNNtNvsy96ehtqc0pt1ax+mkW3QKLCvmtlVnLzRMBrjsJLM5H84Kl+hXGxi5lM uWFybaWkqHh4dROEDc8cPHYFGDx+vVn3fhBhWH+QO6f18398s6OaT7DfwxDddWtXzdUTxY CE0k+XO8D+NjGcflu5fU8rkU0hpYfu8edbIXIUoOWtMHdQcN5bAQo5PrwXZaJQouif62V1 luxUwtfjXLBmOj5EE33i5pAZ5Zzb54aISxIHA/upiAWas2y4/IYYHgO87PpqEg== Received: from [IPV6:2601:644:9381:f410:6096:c3ae:806c:48da] (unknown [IPv6:2601:644:9381:f410:6096:c3ae:806c:48da]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TGGJK25pwz15tj; Thu, 18 Jan 2024 21:35:45 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Thu, 18 Jan 2024 13:35:43 -0800 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: 773c13c686e4 - main - kldxref: skip .pkgsave files Content-Language: en-US To: Warner Losh Cc: Warner Losh , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202302251737.31PHb2R8072300@gitrepo.freebsd.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/6/23 5:35 PM, Warner Losh wrote: > On Wed, Dec 6, 2023, 2:53 PM John Baldwin wrote: > >> On 12/6/23 1:41 PM, Warner Losh wrote: >>> Hey John, >>> >>> On Wed, Dec 6, 2023 at 2:13 PM John Baldwin wrote: >>> >>>> On 12/6/23 1:02 PM, Warner Losh wrote: >>>>> On Wed, Dec 6, 2023, 1:04 PM John Baldwin wrote: >>>>> >>>>>> On 2/25/23 9:37 AM, Warner Losh wrote: >>>>>>> The branch main has been updated by imp: >>>>>>> >>>>>>> URL: >>>>>> >>>> >> https://cgit.FreeBSD.org/src/commit/?id=773c13c686e4b6ae9dbbc150b342b82c3f47d73a >>>>>>> >>>>>>> commit 773c13c686e4b6ae9dbbc150b342b82c3f47d73a >>>>>>> Author: Mina Galić >>>>>>> AuthorDate: 2023-02-25 17:31:58 +0000 >>>>>>> Commit: Warner Losh >>>>>>> CommitDate: 2023-02-25 17:35:43 +0000 >>>>>>> >>>>>>> kldxref: skip .pkgsave files >>>>>>> >>>>>>> This should help people transitioning from traditional setups >> to >>>>>> pkgbase >>>>>>> experience a lot less friction. >>>>>>> >>>>>>> We do this by skipping all files containing two dots. >>>>>>> >>>>>>> Reviewed by: imp >>>>>>> Pull Request: https://github.com/freebsd/freebsd-src/pull/661 >>>>>>> Differential Revision: https://reviews.freebsd.org/D27959 >>>>>> >>>>>> This restriction is too broad and omits all of the modern wifi >> firmware >>>>>> klds from linker.hints, e.g. >>>>>> >>>>>> /boot/kernel/iwlwifi-3160-17.ucode.ko >>>>>> /boot/kernel/iwlwifi-3168-29.ucode.ko >>>>>> /boot/kernel/iwlwifi-7260-17.ucode.ko >>>>>> /boot/kernel/iwlwifi-7265-17.ucode.ko >>>>>> /boot/kernel/iwlwifi-7265D-29.ucode.ko >>>>>> /boot/kernel/iwlwifi-8000C-36.ucode.ko >>>>>> /boot/kernel/iwlwifi-8265-36.ucode.ko >>>>>> /boot/kernel/iwlwifi-9000-pu-b0-jf-b0-46.ucode.ko >>>>>> /boot/kernel/iwlwifi-9260-th-b0-jf-b0-46.ucode.ko >>>>>> /boot/kernel/iwlwifi-Qu-b0-hr-b0-77.ucode.ko >>>>>> /boot/kernel/iwlwifi-Qu-b0-jf-b0-77.ucode.ko >>>>>> /boot/kernel/iwlwifi-Qu-c0-hr-b0-77.ucode.ko >>>>>> /boot/kernel/iwlwifi-Qu-c0-jf-b0-77.ucode.ko >>>>>> /boot/kernel/iwlwifi-QuZ-a0-hr-b0-77.ucode.ko >>>>>> /boot/kernel/iwlwifi-QuZ-a0-jf-b0-77.ucode.ko >>>>>> /boot/kernel/iwlwifi-cc-a0-77.ucode.ko >>>>>> /boot/kernel/iwlwifi-so-a0-gf-a0-83.ucode.ko >>>>>> /boot/kernel/iwlwifi-so-a0-gf-a0.pnvm.ko >>>>>> /boot/kernel/iwlwifi-so-a0-gf4-a0-83.ucode.ko >>>>>> /boot/kernel/iwlwifi-so-a0-gf4-a0.pnvm.ko >>>>>> /boot/kernel/iwlwifi-so-a0-hr-b0-81.ucode.ko >>>>>> /boot/kernel/iwlwifi-so-a0-jf-b0-77.ucode.ko >>>>>> /boot/kernel/iwlwifi-ty-a0-gf-a0-83.ucode.ko >>>>>> /boot/kernel/iwlwifi-ty-a0-gf-a0.pnvm.ko >>>>>> /boot/kernel/rtw8723d_fw.bin.ko >>>>>> /boot/kernel/rtw8821c_fw.bin.ko >>>>>> /boot/kernel/rtw8822b_fw.bin.ko >>>>>> /boot/kernel/rtw8822c_fw.bin.ko >>>>>> /boot/kernel/rtw8822c_wow_fw.bin.ko >>>>>> >>>>>> all match this pattern and are skipped. >>>>>> >>>>>> I'm busy rewriting a bunch of kldxref to be a cross tool using libelf, >>>>>> but I think here you want to probably revert this and just add pkgsave >>>>>> to the list of "known bad" suffixes. >>>>>> >>>>> >>>>> Sure. Any reason to not just require .ko? Or do we have to index the >>>> kernel >>>>> too? >>>> >>>> We do index the kernel as well, yes. However, we could probably get by >>>> with "kernel" and ends in ".ko" as a valid set of files. This would >> also >>>> avoid bogusly warning about linker.hints not being a valid ELF file on >>>> re-runs if you use -v. >>>> >>> >>> Yea, that sounds good. I'll code it up and add you to the review. >>> >>> But why does it matter for these? Firmware is usually loaded by filename >>> and need not be elf... or are these wrapped in elf sections... >>> >>> I haven't noticed it breaking my linuxkpi wifi driver that have >> autoloaded >>> firmware... >> >> Hmm, afaik firmwares are loaded by "module name" where a firmware .ko >> contains >> one or more of the firmware modules. We happen today to generally only >> store one module in a single .ko (and with the same name), and in that case >> kern_linker.c may fallback to just trying to load "foo".ko if it doesn't >> find >> an entry in linker.hints, but if that is why it is working that is >> certainly >> by happy accident. >> >> I only found this by comparing klxref output btw on a stale i386 VM between >> the native kldxref in the VM (before this change) and my cross-arch version >> of kldxref. >> > > Ok. That all makes sense. I'll update my working tree tomorrow with the > revert and the replacement. Since it "works" today, I'll push the revert > and the fix at the same time unless the review takes too long. Ping, do you still have this fix in your pending tree? I noticed it is still there when doing MFC's of the libelf kldxref changes today. -- John Baldwin