Re: [PATCH RFC 0/4] Introduce uts_release

2024-02-21 Thread Masahiro Yamada
On Wed, Feb 21, 2024 at 6:01 PM John Garry wrote: > > 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 expec

Re: [PATCH RFC 0/4] Introduce uts_release

2024-02-21 Thread 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 w

Re: [PATCH RFC 0/4] Introduce uts_release

2024-02-08 Thread John Garry
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 s

Re: [PATCH RFC 0/4] Introduce uts_release

2024-02-05 Thread Masahiro Yamada
On Mon, Feb 5, 2024 at 5:25 PM John Garry wrote: > > 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 agre

Re: [PATCH RFC 0/4] Introduce uts_release

2024-02-05 Thread John Garry
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

Re: [PATCH RFC 0/4] Introduce uts_release

2024-02-02 Thread Jakub Kicinski
On Sat, 3 Feb 2024 00:01:26 +0900 Masahiro Yamada wrote: > I do not see why it is useful. > As you discussed in 3/4, if UTS_RELEASE is unneeded, > it is better to get rid of it. To be clear - the discussion on 3/4 was about the fact that netdev already prints UTS_RELEASE into the version member of

Re: [PATCH RFC 0/4] Introduce uts_release

2024-02-02 Thread Masahiro Yamada
On Wed, Jan 31, 2024 at 7:49 PM John Garry wrote: > > When hacking it is a waste of time and compute energy that we need to > rebuild much kernel code just for changing the head git commit, like this: > > > touch include/generated/utsrelease.h > > time make -j3 > mkdir -p /home/john/mnt_sda4/john

Re: [PATCH RFC 0/4] Introduce uts_release

2024-01-31 Thread Greg KH
On Wed, Jan 31, 2024 at 05:16:09PM +, John Garry wrote: > On 31/01/2024 16:22, Greg KH wrote: > > > before: > > > real0m53.591s > > > user1m1.842s > > > sys 0m9.161s > > > > > > after: > > > real0m37.481s > > > user0m46.461s > > > sys 0m7.199s > > > > > > Sending as an

Re: [PATCH RFC 0/4] Introduce uts_release

2024-01-31 Thread John Garry
On 31/01/2024 16:22, Greg KH wrote: before: real0m53.591s user1m1.842s sys 0m9.161s after: real0m37.481s user0m46.461s sys 0m7.199s Sending as an RFC as I need to test more of the conversions and I would like to also convert more UTS_RELEASE users to prove this is proper

Re: [PATCH RFC 0/4] Introduce uts_release

2024-01-31 Thread Greg KH
On Wed, Jan 31, 2024 at 10:48:47AM +, John Garry wrote: > When hacking it is a waste of time and compute energy that we need to > rebuild much kernel code just for changing the head git commit, like this: > > > touch include/generated/utsrelease.h > > time make -j3 > mkdir -p /home/john/mnt_

[PATCH RFC 0/4] Introduce uts_release

2024-01-31 Thread John Garry
When hacking it is a waste of time and compute energy that we need to rebuild much kernel code just for changing the head git commit, like this: > touch include/generated/utsrelease.h > time make -j3 mkdir -p /home/john/mnt_sda4/john/kernel-dev2/tools/objtool && make O=/home/john/mnt_sda4/john/