[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb8d24cb-b5c4-41be-abf4-33bda08a1059@oracle.com>
Date: Wed, 21 Feb 2024 09:00:26 +0000
From: John Garry <john.g.garry@...cle.com>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: mcgrof@...nel.org, russ.weight@...ux.dev, gregkh@...uxfoundation.org,
rafael@...nel.org, rostedt@...dmis.org, mhiramat@...nel.org,
mathieu.desnoyers@...icios.com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
keescook@...omium.org, nathan@...nel.org, nicolas@...sle.eu,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
netdev@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH RFC 0/4] Introduce uts_release
On 08/02/2024 10:08, John Garry wrote:
> On 05/02/2024 23:10, Masahiro Yamada wrote:
>>>> I think what you can contribute are:
>>>>
>>>> - Explore the UTS_RELEASE users, and check if you can get rid of it.
>>> Unfortunately I expect resistance for this. I also expect places like FW
>>> loader it is necessary. And when this is used in sysfs, people will say
>>> that it is part of the ABI now.
>>>
>>> How about I send the patch to update to use init_uts_ns and mention also
>>> that it would be better to not use at all, if possible? I can cc you.
>>
>> OK.
>>
>>
>> As I mentioned in the previous reply, the replacement is safe
>> for builtin code.
>>
>> When you touch modular code, please pay a little more care,
>> because UTS_RELEASE and init_utsname()->release
>> may differ when CONFIG_MODVERSIONS=y.
>>
>
> Are you saying that we may have a different release version kernel and
> module built with CONFIG_MODVERSIONS=y, and the module was using
> UTS_RELEASE for something? That something may be like setting some info
> in a sysfs file, like in this example:
>
> static ssize_t target_core_item_version_show(struct config_item *item,
> char *page)
> {
> return sprintf(page, "Target Engine Core ConfigFS Infrastructure %s"
> " on %s/%s on "UTS_RELEASE"\n", TARGET_CORE_VERSION,
> utsname()->sysname, utsname()->machine);
> }
>
> And the intention is to use the module codebase release version and not
> the kernel codebase release version. Hence utsname() is used for
> .sysname and .machine, but not .release .
Hi Masahiro,
Can you comment on whether I am right about CONFIG_MODVERSIONS, above?
Thanks,
John
Powered by blists - more mailing lists