Re: [PATCH RFC 0/4] Introduce uts_release

[John Garry]

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