All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hector Martin <marcan@marcan.st>
To: Akihiko Odaki <akihiko.odaki@daynix.com>,
	Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, asahi@lists.linux.dev,
	krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org,
	alyssa@rosenzweig.io, sven@svenpeter.dev
Subject: Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path
Date: Fri, 2 Dec 2022 00:46:38 +0900	[thread overview]
Message-ID: <ae89b38f-fd67-e0e5-1439-f376da985be8@marcan.st> (raw)
In-Reply-To: <c3b0cee9-032c-0447-37df-3ce5ce280e41@daynix.com>

On 02/12/2022 00.19, Akihiko Odaki wrote:
> So I think we should think more about the case when the kernel is booted 
> from m1n1. When using its hypervisor feature, it is more likely that you 
> want console on serial and and that is the opposite of this change. 
> However, it is still possible to get the console on framebuffer with 
> keyboard.

Except if the framebuffer is broken, or everything is broken and it
hangs on early boot, which happens all the time when I'm debugging using
the hypervisor. Or maybe I'm just SSHing in remotely and not physically
in front of the machine, which is also often the case. Or maybe I'm just
booting headless because I didn't feel like swapping around the HDMI cable.

> In contrary, if you boot the kernel without the hypervisor 
> feature and this change, you will completely lose the console.

How so? The console goes to both places with stdout-path set to serial0.
What it *does* change is where input is accepted prior to getty startup
(which is why u-boot specifically conditions this on keyboard presence,
modulo the USB issue - because if you *don't* have a keyboard then tty
keyboard input is useless). But if you're booting kernels without u-boot
along the way, you're probably doing it from the hypervisor or linux.py
anyway, especially if you plan to do something like "init=/bin/sh",
because without u-boot (+ optionally some EFI loader) there is no way of
editing command line arguments at boot time stand-alone.

However, while having stdout-path gives you both serial + tty output and
serial input, *not* having stdout-path kills serial entirely. It also
kills earlycon, and makes it so that you have to specify a bunch of
obscure arguments to get earlycon to work, instead of just a plain
"earlycon" argument which is much easier.

So for this to be considered at all, you would first need to propose a
m1n1 patch to re-add stdout-path in boots under the hypervisor and
(optionally?) on linux.py boots, so you don't regress tools that our
developers use every day.

But I still fail to see the benefit of this change. What scenario are
you envisioning that this would improve (something people actually do,
not a hypothetical)?

- Hector

WARNING: multiple messages have this Message-ID (diff)
From: Hector Martin <marcan@marcan.st>
To: Akihiko Odaki <akihiko.odaki@daynix.com>,
	Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, asahi@lists.linux.dev,
	krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org,
	alyssa@rosenzweig.io, sven@svenpeter.dev
Subject: Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path
Date: Fri, 2 Dec 2022 00:46:38 +0900	[thread overview]
Message-ID: <ae89b38f-fd67-e0e5-1439-f376da985be8@marcan.st> (raw)
In-Reply-To: <c3b0cee9-032c-0447-37df-3ce5ce280e41@daynix.com>

On 02/12/2022 00.19, Akihiko Odaki wrote:
> So I think we should think more about the case when the kernel is booted 
> from m1n1. When using its hypervisor feature, it is more likely that you 
> want console on serial and and that is the opposite of this change. 
> However, it is still possible to get the console on framebuffer with 
> keyboard.

Except if the framebuffer is broken, or everything is broken and it
hangs on early boot, which happens all the time when I'm debugging using
the hypervisor. Or maybe I'm just SSHing in remotely and not physically
in front of the machine, which is also often the case. Or maybe I'm just
booting headless because I didn't feel like swapping around the HDMI cable.

> In contrary, if you boot the kernel without the hypervisor 
> feature and this change, you will completely lose the console.

How so? The console goes to both places with stdout-path set to serial0.
What it *does* change is where input is accepted prior to getty startup
(which is why u-boot specifically conditions this on keyboard presence,
modulo the USB issue - because if you *don't* have a keyboard then tty
keyboard input is useless). But if you're booting kernels without u-boot
along the way, you're probably doing it from the hypervisor or linux.py
anyway, especially if you plan to do something like "init=/bin/sh",
because without u-boot (+ optionally some EFI loader) there is no way of
editing command line arguments at boot time stand-alone.

However, while having stdout-path gives you both serial + tty output and
serial input, *not* having stdout-path kills serial entirely. It also
kills earlycon, and makes it so that you have to specify a bunch of
obscure arguments to get earlycon to work, instead of just a plain
"earlycon" argument which is much easier.

So for this to be considered at all, you would first need to propose a
m1n1 patch to re-add stdout-path in boots under the hypervisor and
(optionally?) on linux.py boots, so you don't regress tools that our
developers use every day.

But I still fail to see the benefit of this change. What scenario are
you envisioning that this would improve (something people actually do,
not a hypothetical)?

- Hector

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-12-01 15:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-01 10:36 [PATCH] arch: arm64: dts: apple: Remove stdout-path Akihiko Odaki
2022-12-01 10:36 ` Akihiko Odaki
2022-12-01 10:36 ` Akihiko Odaki
2022-12-01 14:25 ` Mark Kettenis
2022-12-01 14:25   ` Mark Kettenis
2022-12-01 15:19   ` Akihiko Odaki
2022-12-01 15:19     ` Akihiko Odaki
2022-12-01 15:46     ` Hector Martin [this message]
2022-12-01 15:46       ` Hector Martin
2022-12-01 16:38       ` Akihiko Odaki
2022-12-01 16:38         ` Akihiko Odaki
2022-12-01 17:46         ` Hector Martin
2022-12-01 17:46           ` Hector Martin
2022-12-01 18:14           ` Akihiko Odaki
2022-12-01 18:14             ` Akihiko Odaki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae89b38f-fd67-e0e5-1439-f376da985be8@marcan.st \
    --to=marcan@marcan.st \
    --cc=akihiko.odaki@daynix.com \
    --cc=alyssa@rosenzweig.io \
    --cc=asahi@lists.linux.dev \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=robh+dt@kernel.org \
    --cc=sven@svenpeter.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.