Re: [GIT PULL] ACPI support fixes and cleanups for 7.2-rc1

[Rafael J. Wysocki (Intel)]

On Fri, Jun 26, 2026 at 10:14 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, 26 Jun 2026 at 10:54, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> >
> >  - Unbreak ACPICA tools builds after switching over to using
> >    strscpy_pad() that is kernel-specific (Rafael Wysocki)
>
> Ugh, honestly, this is disgusting.
>
> I've pulled this,

Thanks!

> but this file is not in some kind of "tools"
> directory, so the fact that it then also gets compiled in user space
> should be treated as a user space problem.
>
> I had to really scratch my head how it's even build by user space at
> all, and it's due to absolutely disgusting code in
>
>     tools/power/acpi/tools/acpidump/Makefile
>
> that uses a vpath thing to find that C file for that tool build.
>
> That's just crazy.

I don't dispute your judgement.

The background though is that the code is shared between the kernel
and the tools because the output of those tools needs to match exactly
what is seen and used by the kernel.  Otherwise it might not make much
sense to use them.

> But the fix is *still* not to add horrendous "let's use strncpy() when
> not built for the kernel" in code that looks and acts like kernel
> code. None of the other acpica code does that.

No, it doesn't and the change in question is more of a stop-gap than
something I'd like to be there in the long term.

> How about just adding a trivial strncpy_pad() to
> <acpi/platform/acenv.h> or something. A place that already knows about
> the whole "I'm building the app side" now.
>
> Hmm?

Something like that or define acpi_ut_safe_strncpy() as an alias for
strncpy_pad() when that's available.

I'll figure this out.