From nobody Thu May 25 14:03:14 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 4QRqX53mRvz4V2lk for ; Thu, 25 May 2023 14:03:17 +0000 (UTC) (envelope-from jhb@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 4QRqX52rmJz4GfK; Thu, 25 May 2023 14:03:17 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1685023397; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/c4qwSFzlBNfvtM1zjig/1eY30SZHcT/35OfrtLHlzI=; b=S1lcTSDwEBnoZDzfFBGQVmBeQzr7/doI85LCijjPuBLBlQPUC+OyoMrAP5RMv9hPTnBAVZ xslTpzwicXO0bkhVhXXeBi+hQT7fR5xl+IgGTl3cZwKW/FAAtPZjPvhIB6RjuwEMAHMqFk /irIPxZXUwGMecB80izF9j/DLNArEcZi9dAPy3LGqubn2YM8Y7xBZk34Y7c0Q6nW/3PfSg c725loSArGyOxb8bDdpF0LmnpAun4KYYygoMkRQuXIu3qzm0f82HhWg3kJFQ5G7FauCZMF OpAMIYQjxcEXVMPvHEmrUOYWE27m9w+zjxBq7BJlDEh9iCk62xASoo237Q2+yA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1685023397; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/c4qwSFzlBNfvtM1zjig/1eY30SZHcT/35OfrtLHlzI=; b=V81zEJyA0Ww1C8avOWHVX6/m3I42T3rbzJ7dPdD7mj65ot1UaKsHVcj3j/DhAv7AZD+BIp zJSfOunUDtDBljIQeikIoq3gem8EJNvf8pfOoCjq61/ncqOBdqNDCZg/QWuIR++LcZvUHN 5EP44X2bsJPNKtjwrxERcjb3GxcIdAVjuSrNTR5nDxuOMsWf65dMGz+8T5oWgKpkWCbp1L h7fxw281d2nvoob5ChW4RjyYwhfvF2iQhx8h+dmQ34Y/KSkZ1pAAZtSaCIxazUWSZxRqSP 39p6IVf6u8qz0oGaLh3UUCfQP0EuFYBF4Pp6+mHWjLxiZAjEoZG7uwvwAV7nwA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1685023397; a=rsa-sha256; cv=none; b=UNTlsswhFGTm2BYXZ/oiY0MD5mQHj5kq1wLor6L8OiRjv5lDHu1Vqlw77cOh2qCcm9TcZl 704vAaUXU9bwiM/kLiTnC7I6tT5xW9Bd96ecArHJFm3CpcqEYmYH5/ce0NHTJfU5dfvbuA U8sDc3bUN2ZV3FraX33aG/4dr6eEBf6xuDBLUnXUApfBhOShTCDp5Doz+/P0oyt91sseT6 fxtWOZsbL/1RlDU0Ufj32aqoo3u2OubJDgzUUK0qubwDUjyXrrYJf1HZSpweitXW1FTe3U RXeI1xfvPeE9IXM8eQrY2atgafnDaVme8zXVOZVW3KlvGLGodfrKG6OfE6XWlA== Received: from [IPV6:2601:648:8680:16b0:c0a9:bcae:6c8e:fcb6] (unknown [IPv6:2601:648:8680:16b0:c0a9:bcae:6c8e:fcb6]) (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) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QRqX45tBGzWYY; Thu, 25 May 2023 14:03:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <46e55cd8-a781-32d9-17b4-d836949c58e1@FreeBSD.org> Date: Thu, 25 May 2023 07:03:14 -0700 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [RFC] An idea for general kernel post-processing automation in FreeBSD Content-Language: en-US To: Hans Petter Selasky , Mark Millard Cc: Jessica Clarke , freebsd-arch 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> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N 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.) >>> >>> 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. >>> >>> 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. > > 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. 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). 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. However, I also think that this sub-thread has passed its point of usefulness and should end. -- John Baldwin