Re: [PATCH] riscv: Set SRCARCH to riscv if ARCH is riscv64 or riscv32

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Masahiro,

On 3/30/22 9:34 PM, Masahiro Yamada wrote:
> On Thu, Mar 31, 2022 at 3:40 AM Ben Westover <kwestover.kw@xxxxxxxxx> wrote:
>>
>> Hello Masahiro,
>>
>> On 3/30/22 11:31 AM, Masahiro Yamada wrote:
>>> On Wed, Mar 30, 2022 at 11:34 PM Ben Westover <kwestover.kw@xxxxxxxxx> wrote:
>>>>
>>>> When riscv64 or riscv32 are used as the value for ARCH during compilation, like
>>>> in tools that get the ARCH value from uname, set SRCARCH to riscv instead of
>>>> failing because the riscv64 and riscv32 targets don't exist.
>>>
>>> Can you refer to the code that really needs this?
>> Some software like DKMS compiles out-of-tree modules by running `uname -m`and
>> using that for the ARCH value. Without this patch, that compilation fails because
>> uname shows either riscv64 or riscv32 while riscv should be used.
> 
> It is a bug in DKMS.
> 
> The ARCH=* in linux kernel does not necessarily match to 'uname -m'.
> 
> For example, we use ARCH=arm64 for arm 64-bit (so called aarch64),
> but it does not match "aarch64".
> 
> The kernel has freedom to determine the supported string for ARCH=.
> 
> DKMS must adjust to the kernel code.

Ah, I see. Originally, I opened an issue in DKMS, but they led me to believe it was
a kernel issue. Now I see that *they* are the ones that need to change.

>> This code already exists for sparc and parisc, as well as x86 of course.
> 
> This is because there is a historical reason.
> 
> If you look at the old code  (e.g. 2.6.x,)
> arch/i386/ and arch/x86_64 were separate directories.
> 
> They were unified into arch/x86/ now, but we still support
> ARCH=i386/x86_64.  It helps to choose a different defconfig.
> See arch/x86/Makefile.

This makes more sense now. DKMS based their ARCH value off of uname, and because of
this vestigial code, it worked on x86. Now, trouble is being run into on other
architectures, and their bad design comes back to haunt them.

Thank you for the info; I will now try to solve these issues in DKMS and open a pull
request since they don't seem want to do it themselves.

Regards,
--
Ben Westover

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux