Re: [RFC] An idea for general kernel post-processing automation in FreeBSD
- Reply: Mark Millard : "Re: [RFC] An idea for general kernel post-processing automation in FreeBSD"
- Reply: John Baldwin : "Re: [RFC] An idea for general kernel post-processing automation in FreeBSD"
- In reply to: Hans Petter Selasky : "Re: [RFC] An idea for general kernel post-processing automation in FreeBSD"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 25 May 2023 11:49:28 UTC
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. --HPS > > --HPS