Re: Support to define custom wait events for extensions

On 2023-07-13 09:12, Michael Paquier wrote:
> On Wed, Jul 12, 2023 at 05:46:31PM +0900, Michael Paquier wrote:
>> On Wed, Jul 12, 2023 at 04:52:38PM +0900, Masahiro Ikeda wrote:
>>> If the behavior is unexpected, we need to change the current code.
>>> I have created a patch for the areas that I felt needed to be
>>> changed.
>>> - 0001-change-the-die-condition-in-generate-wait_event_type.patch
>>> (In addition to the above, "$continue = ",\n";" doesn't appear to be
>>> necessary.)
>>
>> die "wait event names must start with 'WAIT_EVENT_'"
>> if ( $trimmedwaiteventname eq $waiteventenumname
>> - && $waiteventenumname !~ /^LWLock/
>> - && $waiteventenumname !~ /^Lock/);
>> - $continue = ",\n";
>> + && $waitclassname !~ /^WaitEventLWLock$/
>> + && $waitclassname !~ /^WaitEventLock$/);
>>
>> Indeed, this looks wrong as-is. $waiteventenumname refers to the
>> names of the enum elements, so we could just apply a filter based on
>> the class names in full. The second check in for the generation of
>> the c/h files uses the class names.
>
> At the end, I have gone with an event simpler way and removed the
> checks for LWLock and Lock as their hardcoded values marked as DOCONLY
> satisfy this check. The second check when generating the C and header
> code has also been simplified a bit to use an exact match with the
> class name.

Thanks for your quick response. I'll rebase for the commit.

Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION