| commit | ae2460d0b8e808078ba130d63514b20b66cd3375 | [log] [tgz] |
|---|---|---|
| author | Andrew Jeffery <andrew@aj.id.au> | Tue May 09 17:12:45 2023 +0930 |
| committer | Andrew Jeffery <andrew@aj.id.au> | Thu May 11 14:45:09 2023 +0930 |
| tree | 9be0e6a522be38173aa93dc79d0bc4171caa00d1 | |
| parent | ba2af9692e491d04e82e5646f531a3ebed409ece [diff] |
obmc-console: Provide a default value for `console-id`.
4e7186918599 ("Fixed broken dbus interface for multiple consoles")
introduced the requirement that `console-id` be specified in the
configuration files for both the client and server. It was paired with a
fix to platform configurations in the OpenBMC bitbake metadata[1]. In
theory this should have worked, but because specifying `console-id`
wasn't a requirement, not all platforms supplied a client configuration.
Instead they relied on the default behaviour.
[1]: https://gerrit.openbmc.org/c/openbmc/openbmc/+/62712
Remove the requirement that a `console-id` be specified and instead
provide a default value that can be overridden by configuration. This
carries forward the consequence from 4e7186918599 ("Fixed broken dbus
interface for multiple consoles") that the original `\0obmc-console`
abstract socket will never be created. This doesn't resolve the break in
ipmid or bmcweb, but resolves the break to SSH-based SOL on platforms
not supplying client configuration files for one of their consoles.
The fix to bmcweb (whose strategy can also be applied to ipmid) is
currently being prototyped[2].
[2]: https://discord.com/channels/775381525260664832/1083551792094249051/1103867159412752424
A deeper treatment of the problems, impacts, and solutions is provided
in [3].
[3]: https://amboar.github.io/notes/2023/05/08/happenings-in-obmc-console.html
Fixes: 4e7186918599 ("Fixed broken dbus interface for multiple consoles")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: I970578f1b695f729f6524c4da6bba6e89bf14d52
To build this project, run the following shell commands:
meson setup build meson compile -C build
To test:
meson test -C build
Running the server requires a serial port (e.g. /dev/ttyS0):
touch obmc-console.conf ./obmc-console-server --config obmc-console.conf ttyS0
To connect to the server, simply run the client:
./obmc-console-client
To disconnect the client, use the standard ~. combination.
This shows how the host UART connection is abstracted within the BMC as a Unix domain socket.
+---------------------------------------------------------------------------------------------+
| |
| obmc-console-client unix domain socket obmc-console-server |
| |
| +----------------------+ +------------------------+ |
| | client.2200.conf | +---------------------+ | server.ttyVUART0.conf | |
+---+--+ +----------------------+ | | +------------------------+ +--------+-------+
Network | 2200 +--> +->+ @obmc-console.host0 +<-+ <--+ /dev/ttyVUART0 | UARTs
+---+--+ | console-id = "host0" | | | | console-id = "host0" | +--------+-------+
| | | +---------------------+ | | |
| +----------------------+ +------------------------+ |
| |
| |
| |
+---------------------------------------------------------------------------------------------+
This supports multiple independent consoles. The console-id is a unique portion for the unix domain socket created by the obmc-console-server instance. The server needs to know this because it needs to know what to name the pipe; the client needs to know it as it needs to form the abstract socket name to which to connect.