[DTrace-devel] [PATCH v2 1/2] translators: support 6.10

[Nick Alcock]

On 19 Jun 2024, Kris Van Hees verbalised:

> This patch breaks generation dlibs for kernels < 6.10...  See bwlow.

Dammit, I tested this! But clearly I messed up the testing :(

> On Fri, Jun 07, 2024 at 07:41:54PM +0100, Nick Alcock wrote:
>> diff --git a/libdtrace/io.m4 b/libdtrace/io.m4
>> index e837ef65b86f7..aa406ec375698 100644
>> --- a/libdtrace/io.m4
>> +++ b/libdtrace/io.m4
>> @@ -1,6 +1,6 @@
>>  /*
>>   * Oracle Linux DTrace.
>> - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2005, 2024, Oracle and/or its affiliates. All rights reserved.
>>   * Licensed under the Universal Permissive License v 1.0 as shown at
>>   * http://oss.oracle.com/licenses/upl.
>>   */
>> @@ -11,7 +11,7 @@
>>   * to replace those tokens with their values to create the finished io.d.
>>   */
>>  
>> -/* #include <linux/buffer_head.h> */
>> +#include <linux/blk_types.h>
>
> This causing a dlib generation failure because this include is not sufficient:

Oh curses.

> The cause seems to be that you should add an include of linux/kconfig.h prior
> to including linux/blk_types.h.  And in all, including linux/buffer_head.h seems
> to be safer because blk_types.h says it shouldn't be included explicitly except
> to break include loops.

The real problem is that the set of valid includes can vary on a
kernel-by-kernel basis... but for now, I guess that'll work.

>>  #include <sys/file.h>
>>  #if 0
>>  #ifndef __USE_UNIX98
>> @@ -43,4 +43,5 @@ DEF_REPLACE(O_NOFOLLOW)
>>  DEF_REPLACE(O_CLOEXEC)
>>  DEF_REPLACE(O_DSYNC)
>>  DEF_REPLACE(O_RSYNC)
>> +DEF_REPLACE(BD_PARTNO)
>
> Thus reports an error when BD_PARTNO is not defined (and that is the case for
> kernels < 6.10).  Wrapping this in #ifdef BD_PARTNO // #endif might be enough
> to fix that.

Yeah, that's, uh, obvious, isn't it! I thought of that, he lies.

Fixing.

(And of course this is arch-specific. Does this mean that every
translation addition requires re-verification of translator generation
on every supported kernel, on every supported arch? Because that's an
incredible drag, particularly given that we have to do it under time
pressure.)

-- 
NULL && (void)