Re: [PATCH RFC 0/4] Introduce uts_release

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

 



On 02/02/2024 15:01, Masahiro Yamada wrote:
--
2.35.3

As you see, several drivers store UTS_RELEASE in their driver data,
and even print it in debug print.


I do not see why it is useful.

I would tend to agree, and mentioned that earlier.

As you discussed in 3/4, if UTS_RELEASE is unneeded,
it is better to get rid of it.

Jakub replied about this.



If such version information is useful for drivers, the intention is
whether the version of the module, or the version of vmlinux.
That is a question.
They differ when CONFIG_MODVERSION.


I think often this information in UTS_RELEASE is shared as informative only, so the user can conveniently know the specific kernel git version.


When module developers intend to printk the git version
from which the module was compiled from,
presumably they want to use UTS_RELEASE, which
was expanded at the compile time of the module.

If you replace it with uts_release, it is the git version
of vmlinux.


Of course, the replacement is safe for always-builtin code.



Lastly, we can avoid using UTS_RELEASE without relying
on your patch.



For example, commit 3a3a11e6e5a2bc0595c7e36ae33c861c9e8c75b1
replaced  UTS_RELEASE with init_uts_ns.name.release


So, is your uts_release a shorthand of init_uts_ns.name.release?

Yes - well that both are strings containing UTS_RELEASE. Using a struct sub-member is bit ungainly, but I suppose that we should not be making life easy for people using this.

However we already have init_utsname in:

static inline struct new_utsname *init_utsname(void)
{
	return &init_uts_ns.name;
}

So could use init_utsname()->release, which is a bit nicer.




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.


  - Where UTS_RELEASE is useful, consider if it is possible
    to replace it with init_uts_ns.name.release

ok, but, as above, could use init_utsname()->release also

Thanks,
John





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

  Powered by Linux