Re: [RFC] An idea for general kernel post-processing automation in FreeBSD

On May 25, 2023, at 04:49, Hans Petter Selasky <hps@selasky.org> 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.

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.
> 


===
Mark Millard
marklmi at yahoo.com