[PATCH] sparc: Use $(kecho) to announce kernel images being ready

[PATCH] sparc: Use $(kecho) to announce kernel images being ready

[Uwe Kleine-König]

My build test setup compiles allmodconfig all various architectures
(arm64 m68k powerpc riscv s390 sparc64 x86_64) using make -s. If there
is no warning, the only output is

          kernel: arch/sparc/boot/image is ready
          kernel: arch/sparc/boot/zImage is ready

from the sparc64 build. Copy the incantation from x86 which is silent
when building with make -s and also mentions a version indication.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 arch/sparc/boot/Makefile | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/sparc/boot/Makefile b/arch/sparc/boot/Makefile
index 45e5c76d449e..339c42d35089 100644
--- a/arch/sparc/boot/Makefile
+++ b/arch/sparc/boot/Makefile
@@ -24,16 +24,16 @@ ifeq ($(CONFIG_SPARC64),y)
 
 $(obj)/zImage: $(obj)/image FORCE
 	$(call if_changed,gzip)
-	@echo '  kernel: $@ is ready'
+	@$(kecho) 'Kernel: $@ is ready' '(#'$(or $(KBUILD_BUILD_VERSION),`cat .version`)')'
 
 $(obj)/vmlinux.aout: vmlinux FORCE
 	$(call if_changed,elftoaout)
-	@echo '  kernel: $@ is ready'
+	@$(kecho) 'Kernel: $@ is ready' '(#'$(or $(KBUILD_BUILD_VERSION),`cat .version`)')'
 else
 
 $(obj)/zImage: $(obj)/image FORCE
 	$(call if_changed,strip)
-	@echo '  kernel: $@ is ready'
+	@$(kecho) 'Kernel: $@ is ready' '(#'$(or $(KBUILD_BUILD_VERSION),`cat .version`)')'
 
 # The following lines make a readable image for U-Boot.
 #  uImage   - Binary file read by U-boot
@@ -59,13 +59,13 @@ targets += uImage
 $(obj)/uImage: $(obj)/image.gz FORCE
 	$(call if_changed,uimage)
 	$(call if_changed,uimage.o)
-	@echo '  Image $@ is ready'
+	@$(kecho) 'Kernel: $@ is ready' '(#'$(or $(KBUILD_BUILD_VERSION),`cat .version`)')'
 
 endif
 
 $(obj)/image: vmlinux FORCE
 	$(call if_changed,strip)
-	@echo '  kernel: $@ is ready'
+	@$(kecho) 'Kernel: $@ is ready' '(#'$(or $(KBUILD_BUILD_VERSION),`cat .version`)')'
 
 $(obj)/tftpboot.img: $(obj)/image $(obj)/piggyback System.map $(ROOT_IMG) FORCE
 	$(call if_changed,elftoaout)
-- 
2.39.2

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[Sam Ravnborg]

On Thu, Jul 13, 2023 at 09:52:35AM +0200, Uwe Kleine-König wrote:
> My build test setup compiles allmodconfig all various architectures
> (arm64 m68k powerpc riscv s390 sparc64 x86_64) using make -s. If there
> is no warning, the only output is
> 
>           kernel: arch/sparc/boot/image is ready
>           kernel: arch/sparc/boot/zImage is ready
> 
> from the sparc64 build. Copy the incantation from x86 which is silent
> when building with make -s and also mentions a version indication.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>

I hope Arnd or someone else can pick it up as davem is not active on
sparc for the time being.

	Sam

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

Hello,

On Thu, Jul 13, 2023 at 04:55:36PM +0200, Sam Ravnborg wrote:
> On Thu, Jul 13, 2023 at 09:52:35AM +0200, Uwe Kleine-König wrote:
> > My build test setup compiles allmodconfig all various architectures
> > (arm64 m68k powerpc riscv s390 sparc64 x86_64) using make -s. If there
> > is no warning, the only output is
> > 
> >           kernel: arch/sparc/boot/image is ready
> >           kernel: arch/sparc/boot/zImage is ready
> > 
> > from the sparc64 build. Copy the incantation from x86 which is silent
> > when building with make -s and also mentions a version indication.
> > 
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> 
> I hope Arnd or someone else can pick it up as davem is not active on
> sparc for the time being.

Nobody did pick this up. Would resending make sense?

The patch still applies to today's next.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[John Paul Adrian Glaubitz]

Hi Uwe!

On Mon, 2023-12-04 at 12:05 +0100, Uwe Kleine-König wrote:
> Hello,
> 
> On Thu, Jul 13, 2023 at 04:55:36PM +0200, Sam Ravnborg wrote:
> > On Thu, Jul 13, 2023 at 09:52:35AM +0200, Uwe Kleine-König wrote:
> > > My build test setup compiles allmodconfig all various architectures
> > > (arm64 m68k powerpc riscv s390 sparc64 x86_64) using make -s. If there
> > > is no warning, the only output is
> > > 
> > >           kernel: arch/sparc/boot/image is ready
> > >           kernel: arch/sparc/boot/zImage is ready
> > > 
> > > from the sparc64 build. Copy the incantation from x86 which is silent
> > > when building with make -s and also mentions a version indication.
> > > 
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > Acked-by: Sam Ravnborg <sam@ravnborg.org>
> > 
> > I hope Arnd or someone else can pick it up as davem is not active on
> > sparc for the time being.
> 
> Nobody did pick this up. Would resending make sense?
> 
> The patch still applies to today's next.

I have reached out to Dave yesterday to find out what the current maintenance
status of the SPARC port is. If Dave needs a new SPARC machine for testing for
example, we can certainly fund one through the community.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[Arnd Bergmann]

On Mon, Dec 4, 2023, at 12:05, Uwe Kleine-König wrote:
> On Thu, Jul 13, 2023 at 04:55:36PM +0200, Sam Ravnborg wrote:
>> On Thu, Jul 13, 2023 at 09:52:35AM +0200, Uwe Kleine-König wrote:
>> > My build test setup compiles allmodconfig all various architectures
>> > (arm64 m68k powerpc riscv s390 sparc64 x86_64) using make -s. If there
>> > is no warning, the only output is
>> > 
>> >           kernel: arch/sparc/boot/image is ready
>> >           kernel: arch/sparc/boot/zImage is ready
>> > 
>> > from the sparc64 build. Copy the incantation from x86 which is silent
>> > when building with make -s and also mentions a version indication.
>> > 
>> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>> 
>> I hope Arnd or someone else can pick it up as davem is not active on
>> sparc for the time being.
>
> Nobody did pick this up. Would resending make sense?
>
> The patch still applies to today's next.

I've applied it to the asm-generic tree now.

Regarding arch/sparc long-term, I think it would be good
if Andreas Larsson could take over as (co-)maintainer,
as he's currently maintaining out-of-tree support for
leon3/4/5, which

My impression from those patches is that they should
pretty much all just get merged anyway. I would also
suggest raising the minimum SPARC32 level to that of
leon3 (SPARCv8e with CAS), which is what glibc requires
anyway for futex().

     Arnd

[1] https://www.gaisler.com/anonftp/linux/linux-2.6/kernel/

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[John Paul Adrian Glaubitz]

Hi Arnd!

On Mon, 2023-12-04 at 14:06 +0100, Arnd Bergmann wrote:
> I've applied it to the asm-generic tree now.

Great, thanks a lot!

> Regarding arch/sparc long-term, I think it would be good
> if Andreas Larsson could take over as (co-)maintainer,
> as he's currently maintaining out-of-tree support for
> leon3/4/5, which

Sounds like a very good idea. FWIW, the SPARC port is currently shaping up
in Debian and Gentoo again with new, faster hardware having been obtained
by both projects.

A new fast SPARC T5 for the GCC Compile Farm accessibly by any open source
developer is also in the works. We're also working on possibilities to test
kernels.

> My impression from those patches is that they should
> pretty much all just get merged anyway.

I agree.

> I would also suggest raising the minimum SPARC32 level to that of
> leon3 (SPARCv8e with CAS), which is what glibc requires
> anyway for futex().

I thought there was user-space emulation for CAS in these cases but I might
be wrong.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[Arnd Bergmann]

On Mon, Dec 4, 2023, at 14:37, John Paul Adrian Glaubitz wrote:
> On Mon, 2023-12-04 at 14:06 +0100, Arnd Bergmann wrote:
>
>> I would also suggest raising the minimum SPARC32 level to that of
>> leon3 (SPARCv8e with CAS), which is what glibc requires
>> anyway for futex().
>
> I thought there was user-space emulation for CAS in these cases but I might
> be wrong.

The problem with emulating CAS is that this needs to be serialized
with sys_futex(). Without Andreas's patches, sparc32 kernels don't
even have provide futex(), so it doesn't work at all. On sparc64
kernels or leon3+ with the futex patch, sparc32 userspace can work,
as long as it uses native CAS, but this would in turn break if
userspace ends up using emulated CAS.

     Arnd

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[Sam Ravnborg]

Hi Arnd.

On Mon, Dec 04, 2023 at 02:06:02PM +0100, Arnd Bergmann wrote:
> I would also
> suggest raising the minimum SPARC32 level to that of
> leon3 (SPARCv8e with CAS), which is what glibc requires
> anyway for futex().

Agreed, it is long time since I got any indications that people
actually use these old machines.
The sparc32 machines I have, have not been powered up for several years
now, and they were only used to test new kernels on anyway.

I sent out a small patch series to do more or less what you suggested
maybe one year ago. Back then the resistance was only from nostalgic
people (like myself) and no real users.

If you or anyone moves forward removing the non-leon sparc32 support
then starting new would be the best approach, I do not think it makes
sense to dig up my old patch set.

	Sam

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[Sam Ravnborg]

On Tue, Dec 05, 2023 at 07:05:06PM +0100, Sam Ravnborg wrote:
> Hi Arnd.
> 
> On Mon, Dec 04, 2023 at 02:06:02PM +0100, Arnd Bergmann wrote:
> > I would also
> > suggest raising the minimum SPARC32 level to that of
> > leon3 (SPARCv8e with CAS), which is what glibc requires
> > anyway for futex().
> 
> Agreed, it is long time since I got any indications that people
> actually use these old machines.
> The sparc32 machines I have, have not been powered up for several years
> now, and they were only used to test new kernels on anyway.
> 
> I sent out a small patch series to do more or less what you suggested
> maybe one year ago. Back then the resistance was only from nostalgic
> people (like myself) and no real users.
> 
> If you or anyone moves forward removing the non-leon sparc32 support
> then starting new would be the best approach, I do not think it makes
> sense to dig up my old patch set.

Never mind, I digged up the old patchset and will try to prepare
something. Then we will see what reception the patch set receives this
time.

	Sam

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[John Paul Adrian Glaubitz]

Hi Sam!

On Tue, 2023-12-05 at 21:26 +0100, Sam Ravnborg wrote:
> > Agreed, it is long time since I got any indications that people
> > actually use these old machines.
> > The sparc32 machines I have, have not been powered up for several years
> > now, and they were only used to test new kernels on anyway.
> > 
> > I sent out a small patch series to do more or less what you suggested
> > maybe one year ago. Back then the resistance was only from nostalgic
> > people (like myself) and no real users.
> > 
> > If you or anyone moves forward removing the non-leon sparc32 support
> > then starting new would be the best approach, I do not think it makes
> > sense to dig up my old patch set.
> 
> Never mind, I digged up the old patchset and will try to prepare
> something. Then we will see what reception the patch set receives this
> time.

No objection this time. But maybe we could sort out the maintainer question
first, then start with new patches.

I like Arnd's suggestion that Andreas Larsson takes up (co-)maintainership.

Can someone reach out to him?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[Andreas Larsson]

On 2023-12-06 10:31, John Paul Adrian Glaubitz wrote:
> Hi Sam!
> 
> On Tue, 2023-12-05 at 21:26 +0100, Sam Ravnborg wrote:
>>> Agreed, it is long time since I got any indications that people
>>> actually use these old machines.
>>> The sparc32 machines I have, have not been powered up for several years
>>> now, and they were only used to test new kernels on anyway.
>>>
>>> I sent out a small patch series to do more or less what you suggested
>>> maybe one year ago. Back then the resistance was only from nostalgic
>>> people (like myself) and no real users.
>>>
>>> If you or anyone moves forward removing the non-leon sparc32 support
>>> then starting new would be the best approach, I do not think it makes
>>> sense to dig up my old patch set.
>>
>> Never mind, I digged up the old patchset and will try to prepare
>> something. Then we will see what reception the patch set receives this
>> time.
> 
> No objection this time. But maybe we could sort out the maintainer question
> first, then start with new patches.
> 
> I like Arnd's suggestion that Andreas Larsson takes up (co-)maintainership.
> 
> Can someone reach out to him?

Hi,
I feel honored to be suggested for such a responsibility. I could in the
long term be available for a role as some kind of SPARC (co-)maintainer,
with backing from my organization. My SPARC experience is mainly with
SPARC32 rather than SPARC64, so discussing a co-maintainership with a
SPARC32 focus would feel natural as a start. I do not have much in terms
of SPARC64 or non-LEON SPARC32 hardware available for testing.

Has someone reached out to Dave? I think discussions like these might
be better served in a thread of its own.

Cheers,
Andreas Larsson

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[Arnd Bergmann]

On Thu, Dec 7, 2023, at 17:49, Andreas Larsson wrote:
> On 2023-12-06 10:31, John Paul Adrian Glaubitz wrote:
>> On Tue, 2023-12-05 at 21:26 +0100, Sam Ravnborg wrote:
>> 
>> No objection this time. But maybe we could sort out the maintainer question
>> first, then start with new patches.
>> 
>> I like Arnd's suggestion that Andreas Larsson takes up (co-)maintainership.
>> 
>> Can someone reach out to him?
>
> I feel honored to be suggested for such a responsibility. I could in the
> long term be available for a role as some kind of SPARC (co-)maintainer,
> with backing from my organization.

Sorry for my late reply, thanks a lot for offering to help out here.

> My SPARC experience is mainly with
> SPARC32 rather than SPARC64, so discussing a co-maintainership with a
> SPARC32 focus would feel natural as a start. I do not have much in terms
> of SPARC64 or non-LEON SPARC32 hardware available for testing.

I think that's all we need at the moment. The lack of an active
maintainer does get in the way of cross-architecture work,
especially when touching the oldest parts of the code.

The most important bit here would be someone with the authority
or Ack or Nak a patch going into another git tree. Even if you
are sometimes wrong, that is still much better than no reply.

On top of that it would be good if you can set up a git tree
for collecting patches to forward to Linus and get included
in linux-next, in place of Dave's orphaned sparc.git.
Once you have an entry in the MAINTAINERS file, you can ask
for an account to host this on git.kernel.org, but other
locations are also fine if you already have something we can
put in the MAINTAINERS entry.

Do you have a preferred place to host a tree?

> Has someone reached out to Dave? I think discussions like these might
> be better served in a thread of its own.

As far as I can tell, Dave has focused mainly on networking and
bpf development rather than sparc for a few years now.

I would suggest that I send him a proposed update to the MAINTAINERS
file with both of you listed as maintainers and ideally your git
tree location replacing his.

Dave can then reply if he has any other preferences (e.g. having
separate sparc32 and sparc64 maintainers, or becoming reviewer
instead of maintainer).

      Arnd

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[John Paul Adrian Glaubitz]

Hi Arnd!

On Mon, 2023-12-18 at 20:52 +0000, Arnd Bergmann wrote:
> > My SPARC experience is mainly with
> > SPARC32 rather than SPARC64, so discussing a co-maintainership with a
> > SPARC32 focus would feel natural as a start. I do not have much in terms
> > of SPARC64 or non-LEON SPARC32 hardware available for testing.
> 
> I think that's all we need at the moment. The lack of an active
> maintainer does get in the way of cross-architecture work,
> especially when touching the oldest parts of the code.

Fully agreed.

> The most important bit here would be someone with the authority
> or Ack or Nak a patch going into another git tree. Even if you
> are sometimes wrong, that is still much better than no reply.

Yep. And there are actually a number of very nice improvements from
Oracle engineers for sparc64 that got never upstreamed. These include
kexec support as well as support for hypervisor control from Linux.

They can all be found in Oracle's Unbreakable Kernel Tree:

> https://github.com/oracle/linux-uek/tree/uek4/qu7

I have already reached out to one of the Oracle engineers and they would
be happy to help us getting some of the patches merged upstream.

> On top of that it would be good if you can set up a git tree
> for collecting patches to forward to Linus and get included
> in linux-next, in place of Dave's orphaned sparc.git.
> Once you have an entry in the MAINTAINERS file, you can ask
> for an account to host this on git.kernel.org, but other
> locations are also fine if you already have something we can
> put in the MAINTAINERS entry.
> 
> Do you have a preferred place to host a tree?

I would choose the same path that I took for arch/sh. Add Andreas as a maintainer
for arch/sparc to MAINTAINERS and then grant access to kernel.org so he can create
his tree there. This makes sure that the tree can be easily located by anyone else
and also get lost because of an external repository becoming unavailable.

> > Has someone reached out to Dave? I think discussions like these might
> > be better served in a thread of its own.
> 
> As far as I can tell, Dave has focused mainly on networking and
> bpf development rather than sparc for a few years now.

Good to know.

> I would suggest that I send him a proposed update to the MAINTAINERS
> file with both of you listed as maintainers and ideally your git
> tree location replacing his.
> 
> Dave can then reply if he has any other preferences (e.g. having
> separate sparc32 and sparc64 maintainers, or becoming reviewer
> instead of maintainer).

I think promoting Andreas as the second maintainer would be an ideal solution.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] sparc: Use $(kecho) to announce kernel images being ready

[Arnd Bergmann]

On Mon, Dec 18, 2023, at 21:02, John Paul Adrian Glaubitz wrote:
> On Mon, 2023-12-18 at 20:52 +0000, Arnd Bergmann wrote:
>
>> The most important bit here would be someone with the authority
>> or Ack or Nak a patch going into another git tree. Even if you
>> are sometimes wrong, that is still much better than no reply.
>
> Yep. And there are actually a number of very nice improvements from
> Oracle engineers for sparc64 that got never upstreamed. These include
> kexec support as well as support for hypervisor control from Linux.
>
> They can all be found in Oracle's Unbreakable Kernel Tree:
>
>> https://github.com/oracle/linux-uek/tree/uek4/qu7
>
> I have already reached out to one of the Oracle engineers and they would
> be happy to help us getting some of the patches merged upstream.

Ah, I didn't know there were so many patches that never made it in.
It does look like they were only in UEK4 (linux-4.1) but not ported
to the later kernels, so it's going to be more challenging to port
these to mainline than the set of leon3 patches that are already on
a recent baseline.

     Arnd