From nobody Mon Jun 13 17:37:31 2022 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 4D371838D1E; Mon, 13 Jun 2022 17:37:38 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4LMJg56v9yz4vm5; Mon, 13 Jun 2022 17:37:37 +0000 (UTC) (envelope-from bz@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655141858; 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: in-reply-to:in-reply-to:references:references; bh=QXfE/66tmEJMmnxyGyDB/1Qcnw09SiWytTvXPuaby/A=; b=iE+A7lQyx3M75LtmJJTThWCJ1GIOeXDCSVNaCcXYmvynZr10jaQ19f9TwJmsbOm7DMYKpR SBbf+22N6Jn3xQQu3Er7BS7/9UkhqH9g9Oh2gNZY/JUzRkmxylSu5Ep4ll5Ebd3wKrZqq0 JdZ1rgrKtAjBd1ifVaztNYnlwId8cIjQUh2VgIR1Y2lux5NFUbygHZH6oN+6+m4/dFLqv1 vMPz47I35IZCr9mihYAd/mQmCr3XNM4TmcLHPEZU8V9ZlOQSXVbiOVdBlqROw+cYYLeHDi pWeKAgxfrQLRRWMJ0bTNIIkLLVdQJqK1gs1jOXLsF3DOdJNIUsBbXN3tzgdiCA== Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 65B612E902; Mon, 13 Jun 2022 17:37:37 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 47A848D4A162; Mon, 13 Jun 2022 17:37:35 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C2E8DE707CD; Mon, 13 Jun 2022 17:37:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id C21MgnODGpcw; Mon, 13 Jun 2022 17:37:32 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 441F9E707B1; Mon, 13 Jun 2022 17:37:32 +0000 (UTC) Date: Mon, 13 Jun 2022 17:37:31 +0000 (UTC) From: "Bjoern A. Zeeb" To: Warner Losh cc: John Baldwin , src-committers , "" , dev-commits-src-main@freebsd.org Subject: Re: git: 0f7b9777f8f3 - main - rtw88: split driver up into a core and pci part In-Reply-To: Message-ID: References: <202206121843.25CIhcLr014633@gitrepo.freebsd.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 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 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655141858; 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: in-reply-to:in-reply-to:references:references; bh=QXfE/66tmEJMmnxyGyDB/1Qcnw09SiWytTvXPuaby/A=; b=jIcOFae6CymWI/5gOOoqnX9i4eaw68zLq2kjVpcq48hCRa7RaFOej155pG22qvvqLY/rQu vhk+/w21lYY61KdbxRXxf0Np475zh3kJNjbmWDHNTkXNhto+J9fgsK+u6TZMg9B6B1kYfU 8DEbfPE6WuUCRFg53Al+pf94a+FNQqLW8u19edCA4GYftAdxuCtAwlqNkrgZQ33nHE/SpE onujLBPjtchK5AvS7gY8Yn0IBnouPJfLuElmklXBCP2dy1JBlzJOLvPMLGdx+m/ozGznTX GEBElDYgSdrTeNGVEZ9fzpZY7ck4n3eMebzNDc8p2W187OSejyQRTgAXqaNlkw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655141858; a=rsa-sha256; cv=none; b=nbM50MRuJN0hwmHPClJekMciEcNoPGGhEBBfLOb+x95qAHcKsYTMgt5x4QQYdvnsPIvU/p RGEIpTAbMPL5Yqzcl5olID+tXY+CJrV7Hf3mD2+xjzjkTLDUi/3oLBUeQ86lgXafdEl17J FdR4gJCvrgWHYeTsrRoJJSceNZEE2EFUFTOUj4kHw6cORaEsALxkOAwAX4zHfo0QiI/RAH xqKYYwvdQo1ET6+Un/0aOlHUY+9EHFOfzpwcdbOuY4pHUVgbi+FWAHc0pNzQQZ37luk6p4 NqKeE8JknroTRmgK01TS0qX077apva5lMhTI2/5iAv17pmwU+wsJBSxvQQ8BVQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, 13 Jun 2022, Warner Losh wrote: > On Mon, Jun 13, 2022, 8:28 AM John Baldwin wrote: > >> On 6/12/22 11:43 AM, Bjoern A. Zeeb wrote: >>> The branch main has been updated by bz: >>> >>> URL: >> https://cgit.FreeBSD.org/src/commit/?id=0f7b9777f8f39fbc230b3e1de2f844d9f839adea >>> >>> commit 0f7b9777f8f39fbc230b3e1de2f844d9f839adea >>> Author: Bjoern A. Zeeb >>> AuthorDate: 2022-06-12 18:35:58 +0000 >>> Commit: Bjoern A. Zeeb >>> CommitDate: 2022-06-12 18:35:58 +0000 >>> >>> rtw88: split driver up into a core and pci part >>> >>> Split the driver up into two modules (if_rtw88_pci.ko and >> rtw88_core.ko). >>> This is in preparation for the hopefully eventually upcoming USB >> support >>> using the same driver core. >>> >>> Note: this changes the module name to load to if_rtw88_pci.ko >> instead of >>> if_rtw88.ko. If using devmatch(8) everything should stay the same >> as >>> the driver name (used for net.wlan.devices) stays rtw88. If using >>> kld_list in rc.conf or loader.conf you will need to adjust the name. >>> Update man page for this. >>> >>> MFC after: 3 days >> >> This sort of split in a .ko is kind of rare for drivers in the tree that >> support >> multiple bus attachments. Usually we just lump all the attachments into >> the same >> .ko. It's true that with the death of ISA, etc. we no longer have as many >> drivers >> with multiple bus attachments, but the norm has been to include them all >> in a >> single .ko. Is there a reason you can't follow the normal practice here? I am not oppsed to one big blob but I wonder if it is "normal practise" these days? I honestly didn't think much beyond PCI is in PCI and USB load where I plug USB in but I couldn't think of many times having both and more code exposure than needed. So you made me go and think a bit about it and look into it: rtwn(4) is split up as "predecessor"; probably also influenced my above thinking. Upstream has this one written in a way that it can be split up natively between buses. In theory I this could be split up into even per-chipset mostly apart from "core" and then one could even start bundling chipset+fw together as an entity but that didn't seem like "common practise". I think the main argument is that this isn't just a few lines of bus attachment but larger parts of the driver (PCI vs. USB to come) given the PCI per-chipset files contain tables etc. and is way bigger than the actual common code (and USB will be fairly small I believe). -r-xr-xr-x 1 root wheel 308536 Jun 13 13:33 /boot/kernel/rtw88_core.ko -r-xr-xr-x 1 root wheel 998712 Jun 13 13:33 /boot/kernel/if_rtw88_pci.ko And I don't neccessarily want to pull in two bus dependencies into the same driver even if that seems the historical way of thinking; "MINIMAL" is still a goal we once set out for and a way of thinking and autoloading does sort things out these days without users having to fiddle anything in the default case. Why do I need to load 1M file for PCI on a machine w/o PCI? Why do we have separate parts for ACPI vs. FDT? Why don't we have NTB support for AMD and Intel and ... together in one .ko? Why is mac-* not one module? Why are geom part implementations not one, or why are congestion control protocols, or ipfw modules separate? Why do I not get Panasonic, Fujitsu, Toshiba and HP ACPI modules on my Thinkpad (even same bus attachments)? Or why do we not put all firmware blobs for the same driver in one file (given firmware 9 can)? Because there is no point in loading 12 firmware images into memory when 1 suffices? Isn't it actually more common to put things apart these days for various reasons? I'd tend to argue that time has moved on and making things self-contained smaller and simpler is a good thing in a too complex world. > Agreed. Furthermore, in the past when a couple of drivers did the we had > issues and confusion. Please don't MFC until this discussion is done. Sure, I'll hold off on that. And given I've been pondering the current state ... could someone please enlighten me on those past issues? I am actually keen to hear them as I have a feeling they might change my entire way of thinking about the current view for a good reason. /bz -- Bjoern A. Zeeb r15:7