From nobody Tue Jun 14 17:42:17 2022 X-Original-To: dev-commits-src-main@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 453068428F6 for ; Tue, 14 Jun 2022 17:42:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 4LMwkL3KX3z3hrb for ; Tue, 14 Jun 2022 17:42:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe36.google.com with SMTP id e20so9686173vso.4 for ; Tue, 14 Jun 2022 10:42:34 -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=h6J2oQe5Zp+hQBnzKxCkgm5rCDt9ArHgZFW6kWKf4AoUpARZleDeozP8Cq5TwiT9Gq CD8h6EGUeTSVl64l89upvMKQp2+w7VQJH3Xrcy6LVZyruApbzq5dNKXghH6muMVIzCdO Q+mRJz7niY7ixXC2zu+aj4bjEMILdut1zmOpBDiGlcoBghfD8XIuvv9gwYTqc1QsbTkz 7A0B4ft5uxfzVLg9+KsllbvO9PexgQCIhY4lI02c0cHz5mMo+Dne1H3Iv7cHlBRd0HfZ 7nORVlxynjJBxpS5igQQgNuQPMZKd4V1DSATCp3PGU2JtdyWm5fk2aeAaIYg4pYhJ4aS rtZw== X-Gm-Message-State: AJIora/UVKW+EdONFl0idfRipl6CO7yE3Pg44MYxeesLmIQRqnimRwLT r191u16EfdaciZ+2dH78fAfh9I+yJmNqN1eH+XDXFw== 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 the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@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: 4LMwkL3KX3z3hrb 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::e36) 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-main@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::e36:from]; MLMMJ_DEST(0.00)[dev-commits-src-main]; 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--