From nobody Thu May 25 14:18:23 2023 X-Original-To: freebsd-arch@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 4QRqss3Dwdz4V3CF for ; Thu, 25 May 2023 14:18:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.205]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRqss0v7Vz4Lfw for ; Thu, 25 May 2023 14:18:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685024318; bh=aznRBgM87F8AXXhrrKdb+UvHnlb9YI0iP+EqudUKz94=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JkhWsjrYUWMCkXT3fSU+bIz4n1J/KjjMjOuwpM4UActpmYzim7EntT2zOFWF6g8wgaZ2648e9i5b3E/MqP9x3fxJu3FA/Aw0yBWAsRGVUMkuhgMejJTvNIWHrUkWogLAihF/JIvyMG0+yPDC1gl4YXhdWp6RIn/PVFEu6TOTv8AHeS8WKrQ6dk+YnmpwvdRT7Gwz7oRPu+wKdgdb92f3EpSYdGQiuTI8KKBsZcpnN+k8PY9y4cU/c1PKGOqZLh3u/rA+SyKgTOBvZkXnt3u0zQpG92qidQ585kReIUUkiQW3r2HhmWBVudGA4Tamg8vv9Un6bpHL0boDc0SsD9pCjg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685024318; bh=DYHgt1zmU0WRo7J8LjW3OgZfAUxPXU7+l5BL01vaOo4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rmgP/ft9rbsarcFUU8gwVNLfymMrTJE+s4DXOkrH8h9/GHKZfKABmR7CkeonyjttXQhe3DNamvcauHQmaQHvbK1mUn1ht28AOtwBQCk9uB+Po8rZnmbBx/0l53AsEKq6gro5nisZmhIM+s2fsruCZK9ykK/Pp4KHejdNN3D23DIoSYWsJMkqGJiRmOWYoyYjTzbHrp64AR0TlhRMJFnkOW1gL12kus039eOxDlRRDhqywzqnMnu5CIHxDpAB66o6KvZ151QZx1emsGkJ+1Ir/T8B9UI7Wi1+hSih/sDdPS27OseOWRwsQZXEQl261r42Z9P8zKww2ZKY12TVmu6Keg== X-YMail-OSG: b1N3cdYVM1lTtAjYRRTvWI72fI_XJ92Dm8M.YReGj0S.zZk1qcsQt6qlDy8wybd tFjtDFdfVVeHrv03E3Na2gPBegV5a8ihsXHYzKc1HEZdgtAXVhB9S.UT84qiDpJY7U.8XO_srP9r RbYUdDvPjMw9pZCE0X3urYmVJD9oegEYQY9yYemqtvsKhBbgJqvLsmfFdiBIopGjW_kMMsRCGOx5 LoUrDpHcN0NkVmg8ajimi2bbKBKjeScTy0rcgDWbVrAs1oorIuZJdplnIB1CNMMp7U3vRf7mVOBC kAuOqeyAMOGG6QelMprPINCAuxWDSWtN8vU4J6paH6UF0Bk3LH873S9baFSjSrQq4DqlYd04j3k7 7ccaK5_viyZZFT6MJwbObgviz81OFVmWzf3hjDCDN6HoSc64tMDKZ2NFdlRvXHCjkw3vG7pXti.J CG7QwTSvY3lSUDUKufuXR47JzI.5HraDsM1Ng0ioCxPnPJovsR4Em6uxl1nXemcu_.lIeG1t7s55 B0vdPNyAKsh.z3c08LhYEkeVVxVi_bdkeSAYcrWVWzMOAQs1lUCVUa96MKGbrCsNDqkbUTn6HSJV dV0AvpE6nAP48apJNiXMD75IEk0NAY1IjdjKpNe.D_eaMv_bbt4hJaAlF3YpbZ.xzeCfxTo27tK4 joehj99tMfwk2D2p0xPnqWGdLwxm1ePfmgGtAeqsnGT6tYJnCdC690Sdx9HFAhAV9XnX.CMPpmoZ spbjz3_o2ta7oTQYCWldPsYRZ4li6Zzbb8YbebfPVOz37uvL1kWEKR0Gh.glOb03dx4iCegINYqY oIryjrFZF5qa8efsN.grIVmOpg._iraLFvK4f_f4qLKphCN0Jm6dDwcxSd6XK7yMonCWrmMa9GZN XCB.CTvHuxxOU..2Nhr.SFdjeyAmpv5dQUaqUPR15FwJg3KR_8nDNPYtADbZ.ruJyWJ5uio5B.ug HeGDFowQVWK2fYrUVlWPxFlRtMKvBub.MSzYVmXdv.ViHR7nFrM8PWNpogAvomPALQi6jEtj86nb RsYY_vzED_fh.GQjNAu9Z3sqFN8UCwCCGi8v1MaYFoo3ZRJ1gKC1EzwLPSkoAxlXZ2Xdn25vSBZS fGi.hcT5tU9hIwTZ7_Ri2KbbsT25IkFY8lQ9r3xGb_D60BhbWBCEpfbeFJN5TDKBkEVs7A2AyKu8 xbnPw2DsW16gqpOA81Z5v0DTEg273WCteg73Dgx1E3y9UJveqJp2GwKTMgdWAO3EIVnlqnwR.rq3 oL9C8QqvTxnh8pDeY6pK2wuPHWrJX5sG1mNV7tB3L_.vJe70BnzXjGNTnY92SqcCQNIY_EUynUu_ 21CJZIaWTJrPv_OAKPmkDccZFqhJfBnYjf5BLvqOhKGXfR3GlKdr06nswCrmoURFgtSPFDV0rm16 c96p1Re_U04TVQFJmSW5esYesJV0NkfNt2Op.EPU7jdylfquO8fUBjvrG7MRmryOjq.3EMBagz7B Xe.OgH9E.b3uJ0J.u8Fl3zVJ3wI6h8gRj9Pi1md.O3o.vI9pUwlwfmE87QQYz86f.PxFj1UcGMuP e.siipOoGJqHw3fRu5P60jzE.ewqr39o6OAWr53fc4cxo4W07XZkmn26BHIyNTO4DmIdIiDUssEb Bv2od_s1mah92C7HNQG.7CykkuVvB5kw6PiqFFlSl.qJmwwHZ2jFYMl84YEvqQkT8P4Sca.iTgIz uJNAlZoOOpuBHBvXQQnNbLkr8WNsus5R1wTmDIxn1r.o33m6mjWKT4dZWJNmQEK_gf1r0Du5Gtzg puw4wynMmwp2WL12sJABqBAeviSgzsy00qCjtyFh75BtEMZRJbEL6nGdG4Z7aqScRulUhPGXUpxB BSDxO9LEnEB0btBJE051EM0x0NMYlbTzYY_ItcJrhCfXw4tSOQ1gt3.tnqUTXV2z1NwvQMRe.DkF 9zkAvQ5l2OmhPHqx8CXXCvX_N3PZU79Nk3hY6JcZZW_mmbNHPN1hTci6f_rWEZPIL5n5I06JnmK7 xQI176NAt4eaeDG48ZdqlLjToJMJFUvsdTnXrPTbseqJkY_ZKmO9pZcyYIjK4BDy9j17SZdzm06S LvhNMYrilX2KrHPSaciodENoMWKZMhzClOjGRpuHV9fKTOt5Fd2PJveogUm8_C.lDKx7M75kSsdY _BB3MlIQZjw0rc_.olC4rCEqbfj12DKfRWWINbvk__kLr1.aqhDDC4UI4PzV7ISfpLl0XvVa88zI .5EHjZ1QGDL_U.EUqf5YT967QpLTfjKj_MU0PTcdPR8xfN9PhnQPX3P0KNzT0ZUy96fjUIbnWOMT Iqj7J X-Sonic-MF: X-Sonic-ID: 11e53fd3-d792-4971-aafc-46f287aa85a3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 25 May 2023 14:18:38 +0000 Received: by hermes--production-gq1-6db989bfb-7p67n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1dc5f357e180138b935510ec10041615; Thu, 25 May 2023 14:18:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: [RFC] An idea for general kernel post-processing automation in FreeBSD From: Mark Millard In-Reply-To: <46e55cd8-a781-32d9-17b4-d836949c58e1@FreeBSD.org> Date: Thu, 25 May 2023 07:18:23 -0700 Cc: Hans Petter Selasky , Jessica Clarke , freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: References: <2EDDC5DC-81C2-4EB8-B729-66F03A8854E4.ref@yahoo.com> <2EDDC5DC-81C2-4EB8-B729-66F03A8854E4@yahoo.com> <6293f06b-927f-432a-3911-808b1d99441b@selasky.org> <9C0CE0A5-150D-4FE1-A838-F1E6A39960F6@yahoo.com> <204FCA67-3FCD-48BA-A373-ABE8AD915D40@yahoo.com> <738F6620-E4FA-4960-87D2-61B93921593C@yahoo.com> <614513c9-06c0-0330-2969-ad4f3ca06569@selasky.org> <46e55cd8-a781-32d9-17b4-d836949c58e1@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QRqss0v7Vz4Lfw X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On May 25, 2023, at 07:03, John Baldwin wrote: > On 5/25/23 4:49 AM, Hans Petter Selasky wrote: >> On 5/25/23 13:42, Hans Petter Selasky wrote: >>> On 5/25/23 12:57, Mark Millard wrote: >>>> The pre-existing code expresses explicitly that no other >>>> routine is allowed to have its own use of the mutex, a >>>> design choice enforced by the compiler as things are >>>> written. (The purpose of the limitation to block scope.) >>>>=20 >>>> Your proposed change removes the compiler enforcement of >>>> that design, allowing use of the mutex by other code in >>>> mlx4_main.c without any notification by the compiler. >>>>=20 >>>> Your proposal has a direction of being more fragile for >>>> bad changes without having to be explicit in code updates >>>> about the change of status. >>>=20 >>> Hi Mark, >>>=20 >>> Looking only at the mutex part alone, you are right, but not when = also >>> considering the SYSINIT() part, as implemented in LinuxKPI = currently. >> To be more precise: >> The static mutex can only be accessed from within the routine itself, >> when it is part of a block scope. That is expected. >> However the static sysinit, which is also inside the block scope of = the >> function, is accessed from _outside_ the function. >> This might be viewed as a violation of the block scope limitation. >> Therefore the DEFINE_MUTEX() should be outside the block scope, due = to >> how it is implemented in the LinuxKPI currently. >=20 > I don't think you are correct here. A sysinit is much like a = constructor, > and it's perfectly valid to pass a pointer to an object that can not = be > accessed by name outside of a scope to some other bit of code outside = of > that scope (e.g. a constructor). I guess that must happen indirectly via mutex_lock(&set_port_type_mutex); and: mutex_unlock(&set_port_type_mutex); but I missed how when I looked. > It's not even just the SYSINIT. You are > passing a pointer to this function-static variable to routines like > sx_xlock, etc. as well which is also outside of scope, but that's = perfectly > fine. The scoping rules are about when the compiler can resolve the > variable by name, not restricting which bits of code are able to = access > the variable by reference/pointer. >=20 > However, I also think that this sub-thread has passed its point of = usefulness > and should end. Okay. But my understanding was that there was still an intent to reintroduce the change. I still do not expect that I've solidly understood the justification for the original change, if it is, in fact, needed. I did view the material about the "SYSINIT() part" being what was involved as some progress for that. May be off list would be better if I'm to get to a solid understanding. =3D=3D=3D Mark Millard marklmi at yahoo.com