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