From nobody Tue Jun 14 17:42:17 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 61570842942 for ; Tue, 14 Jun 2022 17:42:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LMwkD5KNrz3hrD for ; Tue, 14 Jun 2022 17:42:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe30.google.com with SMTP id j39so9658308vsv.11 for ; Tue, 14 Jun 2022 10:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UNOb0RENiKo4tbk9ujGbbgVDaeZ/lrEvFTmoH/cExA8=; b=Us6CkANL7LIivC2cvfnk+CdVuyIN1s+ZV8L2Ckqzh/w0HZ/W7lnUq6VX31ArP4rNLv X+o2juqp6Z8xgjZhEgAwTDfzr0MPble5BNbLI9Va9NgYj9Zxzs5z+oApr+6xQV7GSZ7l UlTq3l5bSqjfXMODb3lGZi4A+ENMC8SFrppas2gxRxtE38Iqpgxynn0aNfXlJybCnuxP aNqjb1+OX+bFK2apwp9nN770H2JqkoRUlYw7fYzFxMbOcF0e/WflgLHC/vOdLEJ+vyjt kKwmtvNk4R2OOcejylDiYriLpO/yMiSX9NKUx9oPVzZHndsCQ7KNPl3du4x1BuurMdf7 ybew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UNOb0RENiKo4tbk9ujGbbgVDaeZ/lrEvFTmoH/cExA8=; b=5uSEuKjFpqQ5lnPNWZBzJdPbqPFc4w8j3/qprZ+Deoq0nY1clc+51DJq5v1KUIxpQU Egi/Aqjzfj0CKFRWe/9SlbQAg60CuVb9V2V5I+eDF8u3lZQnzkfhlRkBo5p7HGtdblRO iZ+oA2a51boMYyHciGF0jBupAnQZMSWPQM5gcp1B99SImGpcmGoIp+wbH4tu4nmJXW8D 49RZq0/vQ0MkudI+QtEXucs3wqmlH8mc08ZmT+qb2ubPqHiYeakDPAObQ7vRnEXZDYbn xJDdx7stuE9dnpwhCIkSPt/402R2/INEdHvJgdbRACLz+b+8cGkeXSTMFq4o0imenupA zcVQ== X-Gm-Message-State: AJIora/OaXnZWaucsNiSD9mI9OO2LuyKRFqqcQtNvYVgE6WPTIt7CaZl u8Q0L6t0PoYRzV+utGYmURmxTnceRyhamnmAbBD9Aw== X-Google-Smtp-Source: AGRyM1tWUVx0qBiISmyD1YvT2YBZUqik1JR0LtpYX3FVMQ1reMV4eDggkOHsBRlqFyGwrYVNfOvkv11Jyu4EMm/Nzmw= X-Received: by 2002:a67:7186:0:b0:34b:a3f6:c6fd with SMTP id m128-20020a677186000000b0034ba3f6c6fdmr2862262vsc.53.1655228548441; Tue, 14 Jun 2022 10:42:28 -0700 (PDT) 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 References: <202206121843.25CIhcLr014633@gitrepo.freebsd.org> <0e2172f8-21c1-afb1-9d2b-03ef14a4edf5@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Tue, 14 Jun 2022 11:42:17 -0600 Message-ID: Subject: Re: git: 0f7b9777f8f3 - main - rtw88: split driver up into a core and pci part To: "Bjoern A. Zeeb" Cc: John Baldwin , src-committers , "" , dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="000000000000a6fdb605e16bed27" X-Rspamd-Queue-Id: 4LMwkD5KNrz3hrD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Us6CkANL; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e30) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-all@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.997]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e30:from]; MLMMJ_DEST(0.00)[dev-commits-src-all]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000a6fdb605e16bed27 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 14, 2022 at 11:12 AM Bjoern A. Zeeb wrote: > On Tue, 14 Jun 2022, Warner Losh wrote: > > [..] > >> parts with different user interfaces. However, if you are going to have > >> the > >> 'foo0' interface, we assume that it loaded by 'if_foo.ko'. ifconfig(8) > >> even has this knowledge baked in. > >> > > > > Yea, I wasn't sure how to respond to what seemed like a non sequitur > here, > > but I like your reply... > > > > It points out a large reason we did this: ifconfig ed0 loads if_ed > > automatically and if we had if_ed_isa.ko, if_ed_eisa.ho, etc then this > > would break. > > That was certainly true back then. > > But that is basically a bandaid for cloned interfaces these days? > No. It isn't. > All others on a real bus having "PNP" information devmatch will have loaded > before ifconfig is run the first time these days? "The world is changing" > If the world is changing, we should have a plan for the change. Not just start to do random things that wind up breaking other things when people with a different use-case follow along. If the world has changed, we should remove the automatic loading from ifconfig, but that would break many other use cases that aren't real hardware. But we don't have to break things, and "the world is changing" isn't quite the right argument to use here. But really, a big part of the problem is that we've built so much on top of config(8) and that should be the problem we're solving. It could automatically create a if_foo_pci.ko, if_foo_usb.ko and a if_foo.ko that depends on them both so that if you automatically load the right thing, it all works, but if you rely on something else to load it, that will still work, but less optimally than if it came in via PNP data should that functionality be disabled for some reason. Warner --000000000000a6fdb605e16bed27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 14, 2022 at 11:12 AM Bjoe= rn A. Zeeb <bz@freebsd.org> wro= te:
On Tue, 14 J= un 2022, Warner Losh wrote:

[..]
>> parts with different user interfaces.=C2=A0 However, if you are go= ing to have
>> the
>> 'foo0' interface, we assume that it loaded by 'if_foo.= ko'.=C2=A0 ifconfig(8)
>> even has this knowledge baked in.
>>
>
> Yea, I wasn't sure how to respond to what seemed like a non sequit= ur here,
> but I like your reply...
>
> It points out a large reason we did this: ifconfig ed0 loads if_ed
> automatically and if we had if_ed_isa.ko, if_ed_eisa.ho, etc then this=
> would break.

That was certainly true back then.

But that is basically a bandaid for cloned interfaces these days?

No. It isn't.
=C2=A0
All others on a real bus having "PNP" information devmatch will h= ave loaded
before ifconfig is run the first time these days?=C2=A0 =C2=A0"The wor= ld is changing"

If the world is ch= anging, we should have a plan for the change. Not just
start to d= o random things that wind up breaking other things when people
wi= th a different use-case follow along. If the world has changed, we should
remove the automatic loading from ifconfig, but that would break m= any other
use cases that aren't real hardware. But we don'= ;t have to break things, and
"the world is changing" is= n't quite the right argument to use here.

But = really, a big part of the problem is that we've built so much on top of=
config(8) and that should be the problem we're solving. It c= ould automatically
create a if_foo_pci.ko, if_foo_usb.ko and a if= _foo.ko that depends on them both
so that if you automatically lo= ad the right thing, it all works, but if you rely on
something el= se to load=C2=A0it, that will still work, but less optimally than if it cam= e
in via PNP data should that functionality be disabled for some = reason.

Warner
--000000000000a6fdb605e16bed27--