Linux Test Project
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Tiezhu Yang <yangtiezhu@loongson.cn>
Cc: "Ricardo B. Marliere" <rbm@suse.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] device-drivers/acpi/ltp_acpi_cmds: Fix build errors
Date: Thu, 17 Jul 2025 16:09:07 +0200	[thread overview]
Message-ID: <20250717140907.GA11016@pevik> (raw)
In-Reply-To: <51cdca77-e93e-7df5-e50a-7604c2a3cb10@loongson.cn>

Hi Tiezhu, all,

[ Cc Jan and Ricardo in case I overlook something ]

> On 2025/7/15 下午5:24, Andrea Cervesato wrote:
> > Hi!

> > On 7/11/25 10:01 AM, Tiezhu Yang wrote:
> > > There exist the following errors when building LTP:

> > >    ltp_acpi_cmds.c:39:10: fatal error: linux/genhd.h: No such file
> > > or directory
> > >    ltp_acpi_cmds.c:131:18: error: implicit declaration of function
> > > 'acpi_bus_get_device'
> > >    ltp_acpi_cmds.c:400:18: error: implicit declaration of function
> > > 'acpi_bus_get_device'

> > > For the first error:

> > > This is because genhd.h has been removed in the Linux kernel, the
> > > contents
> > > of genhd.h was folded into blkdev.h [1]. Since blkdev.h has been included
> > > in the C file, just remove unused include genhd.h to fix the build error.

> > > For the second and third errors:

> > > This is because acpi_bus_get_device() has been droped in the Linux
> > > kernel,
> > > in order to fix the build errors, just replace acpi_bus_get_device() with
> > > acpi_fetch_acpi_dev() like the kernel commit [2].

> > > [1] https://git.kernel.org/torvalds/c/322cbb50de71
> > > [2] https://git.kernel.org/torvalds/c/ac2a3feefad5

> > These patches have been introduced in v5.18, but we support kernel until
> > v4.4. If we really want to keep this code,

> There are fatal errors about the following two files:

> testcases/kernel/device-drivers/tbio/tbio_kernel/ltp_tbio.c
> testcases/kernel/device-drivers/acpi/ltp_acpi_cmds.c

> I guess they are not used frequently.
> I am not sure what is the proper way to handle this case.

> (1) just keep it as is
> (2) remove them entirely
> (3) adjust them for different kernel versions

First, thanks a lot for looking into LTP test kernel modules. Indeed
ltp_acpi_cmds.ko and ltp_tbio.ko source code do not compile on newer kernels and
there are more of them using linux/genhd.h (but only ltp_acpi_cmds.ko uses
acpi_bus_get_device()). But Andrea is correct we want to care about old kernels
up to 4.4 (see [1]).

@@ -36,7 +36,6 @@
 #include <linux/ioctl.h>
 #include <linux/pm.h>
 #include <linux/acpi.h>
-#include <linux/genhd.h>

Due the above could you please take the approach Ricardo did in 82e38a1f24
("block_dev: Convert to new API") - wrap with ifndef?

#ifndef DISK_NAME_LEN
# include <linux/genhd.h>
#endif

BTW I would personally use #ifndef HAVE_LINUX_BLKDEV_H than checking for
DISK_NAME_LEN as we already check for linux/blkdev.h in configure.ac, but that's
a minor detail.

> Furthermore, I found there are many warnings except the above
> fatal errors, is it necessary to silence them or keep it as is?

> > we need to use autoconf in order to recognize acpi functions and to
> > create a fallback file in lapi/genhd.h like we usually do for the older
> > API.

> > https://github.com/linux-test-project/ltp/blob/master/configure.ac
> > https://github.com/linux-test-project/ltp/tree/master/include/lapi

Yes we need to #if #else macros for acpi_bus_get_device() vs.
acpi_fetch_acpi_dev().

The timeline of relevant changes in kernel:
5.17-rc1: added acpi_fetch_acpi_dev()
5.18-rc1: removed linux/genhd.h
5.18-rc2: removed all remaining uses of acpi_bus_get_device()
5.19-rc1: removed acpi_bus_get_device()

Both functions are in drivers/acpi/scan.c, and prototype is only in kernel only
header include/acpi/acpi_bus.h - out of UAPI exported to user space.

It looks to me that we can happily expect that acpi_bus_get_device()
can be used only with linux/genhd.h. That makes things simple, because if I'm
wrong the detection would have to be added as a custom macro in m4
(probably just extend m4/ltp-kernel_devel.m4) because AC_COMPILE_IFELSE() which
is in configure.ac is IMHO not possible to use for kernel modules.

And yes, you could write macro in newly created include/lapi/module.h to hide
ifdef but IMHO not worth just for these 2 functions (used only in
ltp_acpi_cmds.ko). FYI info about lapi in old doc [2]

FYI LTP autotools kernel related helpers:
* include/mk/module.mk (used to compile kernel modules)
* m4/ltp-kernel_devel.m4 (detect support for building modules, e.g.
whether are kernel-default-devel-* openSUSE or linux-kbuild-* packages
installed)

Kind regards,
Petr

[1] https://linux-test-project.readthedocs.io/en/latest/users/supported_systems.html#kernel-version
[2] https://github.com/linux-test-project/ltp/blob/master/doc/old/C-Test-API.asciidoc#lapi-headers

> If necessary, will try.

> Thanks,
> Tiezhu

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2025-07-17 14:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-11  8:01 [LTP] [PATCH] device-drivers/acpi/ltp_acpi_cmds: Fix build errors Tiezhu Yang
2025-07-15  9:24 ` Andrea Cervesato via ltp
2025-07-15 11:23   ` Tiezhu Yang
2025-07-17 14:09     ` Petr Vorel [this message]
2025-07-18  3:59       ` Tiezhu Yang
2025-07-18  6:30         ` Petr Vorel

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=20250717140907.GA11016@pevik \
    --to=pvorel@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=rbm@suse.com \
    --cc=yangtiezhu@loongson.cn \
    /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