From: Kris Van Hees <kris.van.hees@oracle.com>
To: Nick Alcock <nick.alcock@oracle.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH v2 1/2] translators: support 6.10
Date: Thu, 20 Jun 2024 13:54:01 -0400 [thread overview]
Message-ID: <ZnRsuWoGg3DkX7RM@oracle.com> (raw)
In-Reply-To: <87cyodaxau.fsf@esperi.org.uk>
On Wed, Jun 19, 2024 at 02:15:21PM +0100, Nick Alcock wrote:
> On 19 Jun 2024, Kris Van Hees stated:
>
> >> -/* #include <linux/buffer_head.h> */
> >> +#include <linux/blk_types.h>
> >
> > This causing a dlib generation failure because this include is not sufficient:
> >
> > In file included from /home/kvanhees/linux-uek/arch/x86/include/asm/pgtable_types.h:380,
> > from /home/kvanhees/linux-uek/arch/x86/include/asm/processor.h:21,
> > from /home/kvanhees/linux-uek/arch/x86/include/asm/cpufeature.h:5,
> > from /home/kvanhees/linux-uek/arch/x86/include/asm/thread_info.h:59,
> > from /home/kvanhees/linux-uek/include/linux/thread_info.h:60,
> > from /home/kvanhees/linux-uek/include/linux/spinlock.h:60,
> > from /home/kvanhees/linux-uek/include/linux/wait.h:9,
> > from /home/kvanhees/linux-uek/include/linux/wait_bit.h:8,
> > from /home/kvanhees/linux-uek/include/linux/fs.h:6,
> > from /home/kvanhees/linux-uek/include/linux/highmem.h:5,
> > from /home/kvanhees/linux-uek/include/linux/bvec.h:10,
> > from /home/kvanhees/linux-uek/include/linux/blk_types.h:10,
> > from libdtrace/io.m4:14:
> > /home/kvanhees/linux-uek/include/asm-generic/pgtable-nopud.h:18: warning: "PUD_SHIFT" redefined
> > 18 | #define PUD_SHIFT P4D_SHIFT
>
> Not observed on 5.4.17, nor on 5.15.0. What kernel is this with?
Upstream 6.9.3 and 6.9.5
> > 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.
>
> Oops, I didn't look at the header comment because it's usually just a
> copyright message :)
>
> It works, but at first sight it's not obvious how linux/buffer_head.h
> defines BD_PARTNO: I guess it's doing it transitively via some tangle of
> other headers. I guess it's always going to include blk_types.h
> *somehow*, so I suppose it's safe.
>
> --
> NULL && (void)
next prev parent reply other threads:[~2024-06-20 17:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-07 18:41 [PATCH v2 1/2] translators: support 6.10 Nick Alcock
2024-06-07 18:41 ` [PATCH v2 2/2] dlibs: pregenerated translators for 6.10 Nick Alcock
2024-06-13 12:22 ` [DTrace-devel] " Alan Maguire
2024-06-14 12:25 ` Alan Maguire
2024-06-19 13:23 ` Nick Alcock
2024-06-19 3:32 ` [PATCH v2 1/2] translators: support 6.10 Kris Van Hees
2024-06-19 12:41 ` Nick Alcock
2024-06-19 13:15 ` Nick Alcock
2024-06-20 17:54 ` Kris Van Hees [this message]
2024-06-19 13:21 ` [PATCH v3] " Nick Alcock
2024-06-20 17:55 ` Kris Van Hees
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZnRsuWoGg3DkX7RM@oracle.com \
--to=kris.van.hees@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=nick.alcock@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox