All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.