From nobody Thu May 25 13:37:33 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 4QRpym494Dz4V1PK for ; Thu, 25 May 2023 13:37:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 4QRpym1h4jz488Q for ; Thu, 25 May 2023 13:37:52 +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=1685021870; bh=EcsebdFj3CYp/J1JQ79a0nBPddoGuAcNpb2ga99oVTw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bL+55nnzsJVeWHDEszi7M246qu0uVoyjXccwjo2dlPwLW7nPyyNaDrqkZ+QZKKVRKnmZBmqBX+saseq+RFH4RwmkKAFpbJ6taKGSr7ikzywngivhs6adO79e5BGxWKBOjV2lNmg58az1HgiBap3yOjo5cIbq9v/QMj4s+Pwzb2YMVL88zVKlw3hXOylV4nqQEqoJc1IlngT0vQt2BTYiAjYuZaKAekR7ZUOL262AqvIepeFiQeciNO2NtTHV2ddS4a7auCBg5sYUxwbuzbStfWeaVy4U8BUaGMycs4DIWWr5bJt9/h8ewsH86EkMvzrwXhi5vDH8g3OEjpEp5qAIvQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685021870; bh=K/Pu8qhaQWX8rAFa0RezMIu/ciM7sLeD/vl/VDGKVjw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oHouoIFnE7Z/0PEZUjVMliGCdFAiUSgxHNHFqZLcIqxJi1LP2elsRAFCCR9UNrO9ToBedD1RyIZuYEOORGELQ8i2aDlosrEdntWR6abFmFwyp3LOfAsTpK/uy1ghu/dhAkMk5xn259rWEM5zfIYaBiWBSnArPWhTVTznNVXHJ536dIuB2rDBTnnW8U+DSJQul5EI9jhSOslpDLVXtWYGpba+NIRI+LVXTAmY9fYhaazw9BPpHVC5dt00ifwbXDyPPag8/G+YnHCUfd4bxnqCgBY1TAY27h1+fMnK3xF0TpCzk2v/CgXiiCV5cM5yYI/DJafS8a6v+8vSoJ9tLd0SEg== X-YMail-OSG: dXznnlcVM1m9CB8nOHE.BPay_PQxwDn0t.Q7prDBHZA4nGwWzhf5H8KPuOv7JAe MWPJVqCkrgVJgKE_.MRka3Zmx.jmIFxrRdMAGoVj6lNIZXlXQt15xdrZRAjKtROUkfBgYRYJX4F6 NM_956AaLpRuheSK.ooe.zns4_VMrZVpMED9XfmLsFDTXOjk5UpKGkCnUKsa_yQJduZ4eLgnlQSh 3M_3WMTg1ynFIU.v2vo6rBHNigSf_vTBk6hJKZwEbkJI4wLS1IvxUow44AcNgRqiC2O2XpNaUb0W x.GVrlvXV_eLLvd5yAFCVcyaCU9rALG1jfbVYjnxwp87SvDNf2ng.7z99aDNMHKpTH9l_rVJhPiF nsFQHcEMcfljG7mrsrc_5VJBYFXniDIJX1hEzpIcFctkUkxNP81ZM7e4Ql.6pFVfTZAu6HKnCwux yDa8Ov6..URazwdwUPZqpKKhmAuTq7Tq1Nva8iL0P0AqByGXM2t7NIHzH8ftLnEcphvLj2TIknFK tzPs.c4TQQhEbbiZWGAGezAAknbwhFNa4v7J9eVnLChfpi5kgBuFSyEAgBGS5LY8KzuQf0yebsB2 V4WShIr7T_yHeZ8eR_JYobPOOsL.StbAEHxHxsK9KJ0j7MW_eqFwHU3Rz38K9GXxVVjoQ3EiF8k4 wd4GnDNPRLqvkbCZfGHG2c_z4nyndZosXylF3Hqcq.TwD.bipQQVC1EcpdyOMKnx2oKiV3EuOmgP uTbp4KusYNmcbV6zwasR_nztSeMo8BxI2Z12u1sDpHGQ00JeLpU.z43QduvY.Gchi8jfSx.PKoXD bOHXbArKI7sDJU2Vf61HxKMS.CqVfGWg58XVra3xx1wIozL_TNrcGzHc667kGCQJZGwubgNcFFpy ZPCQ5iLx9kwmuSWv2ks1UWJ0ZxUWwOaOyHCR_KTIbDwolbBCwEq0M_D22Ml6j7HxGmoCH0rFKwsd zniGagzOzvkafJl0JvZD17VAiq7O0Z75Ezt5qVfNc5DOvdj6FvSoC0NnXvQgab3PDfOOcZYevHo4 W7h3ZueaXAeTwjvsUN6Iq0Dgdrzi8ZEyBdqLFuFwmXl3g3.jgGWiM8NlYzelRjeJ6bnClvZ41kWO KB5R0JAk5kJstGDTLC.8422xe0wgtoOkSBAw6ESMFxlR5TbXf.lr2BeagNjuCW2SL0xSaA30ScO. R7VOcwUq_QcmWYnGM4z1oO7MlZCwlrL_eKGvprxb.flhqHemYrIU3gvL2nl_sneImuH5zie8HCU8 UWHXrHnIRNFaSqHBHRqG57eWzm.LFgpcOletORQ9Gq7f0ZhA3jdE5i.lbRP2joeB3PmBBNQG6KlP Dc9NWtt0FxbnLF3i6no_IMd1PdHkpv7lMM8nIrNnxjlfYqDW7fgwlT6qtzoHDEiZcha1YV_0YLiq dkH9E4I3WElczoNR98AolRbc2BDDAEctAjH1GUadSRar.fF0XgHUPPc3js0eNqRybLJPdbxDnR3z 66ucncFoA_Wxsx28rgFV.5LhrY5nMuQYTupJFLcnggohCabhNniAls82nztxUATyWsVIfUxGJJKE hNTjavqlC3SsCfLeRCWicM9lQXMD5u_RWi6IAAdHjdo8y9ejYx1DbM231W7YFlAr.NKrqhKgz9JW sYuuAXnqZBu4C9Im80jgLtt77aPzAYAo5tHJJrto9mbr7C_Ow8tKBNwD.WvYz5c2IIBi_FgYR5iM jZ6xUD5.GujXxIACaI0tFFrGn7z43UGLb8.ar5QTYPVYv.ByHsm25lNnLqPRYkZN8Eqoi4FXMSv9 VpxE7N6n2XQvymIJfLASh774fkLS.kHvRk7COTp0kcnFwhsewgn4H95CSJPuFFBnKPk0KLcqnwbW .2eUwaAut7oowsP5G2zAwVV6Hl_sLbzspCQqb4L2jfVwWo1HOGeoIFr3UEiHu8bmtDgPV6wcrRRf _gsixZgt_5ZGIcP3RRrhBbNWO4EToa8zVB1XTWVZJ622.h85sGUHc.HkVa8wgNETEnZ0YTjWPMl3 lXxq9Qta7j6P1bENeJVzIIZNJCpzxg1VTe3VpFgMyWegg8leevLaN2vxEkihYezIhA1MwUYUP1Lf SXFF0nghYOmScAS6nhES0hfAPGVT6ZAJxyoZRQThNBSVJnkVUa.QodzzQ0naADoyH.irxo6GxRTZ BWdLvIAIoTZeeQ3n90dJ07.JpkRKjOU3ZwJRjRKTy7tZSwcxHhGXvF7IH_rjS.hfM.DIKAWfKliP MlSJr08SGrVFZ1CXm9OVrB5ZbYhvgnNq3bGS3bHzyOk1t.iQtMjucMYq7HCj5S62LMLWWAhS0CE0 Odvto X-Sonic-MF: X-Sonic-ID: 5c55d43d-e4d9-46a7-885b-d90b2440f910 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 25 May 2023 13:37:50 +0000 Received: by hermes--production-bf1-54475bbfff-gh86g (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f3931c5a0ca7e026de411513e0dfeb4f; Thu, 25 May 2023 13:37:46 +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: Date: Thu, 25 May 2023 06:37:33 -0700 Cc: 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> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QRpym1h4jz488Q 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 04:49, 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. >> Hi Mark, >> Looking only at the mutex part alone, you are right, but not when = also considering the SYSINIT() part, as implemented in LinuxKPI = currently. >=20 > To be more precise: >=20 > The static mutex can only be accessed from within the routine itself, = when it is part of a block scope. That is expected. >=20 > 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. What mechanism gets access to the static sysinit from outside the block scope? It would have to be something from outside the C language standard's coverage. Or is it the other way: access is needed for correct operation but does not happen because of limited access in the language? > Therefore the DEFINE_MUTEX() should be outside the block scope, due to = how it is implemented in the LinuxKPI currently. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com