History log of /freebsd/usr.sbin/bhyve/uart_backend.c (Results 1 – 4 of 4)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# ad152571 02-Oct-2024 John Baldwin <jhb@FreeBSD.org>

bhyve uart: Fix errors from GCC

- Place 'static' before other qualifiers (-Wold-style-declaration)

- Correct the order of arguments to calloc (-Wcalloc-transposed-args)

Reported by: GCC 14
Fixes:

bhyve uart: Fix errors from GCC

- Place 'static' before other qualifiers (-Wold-style-declaration)

- Correct the order of arguments to calloc (-Wcalloc-transposed-args)

Reported by: GCC 14
Fixes: 1f903953fbf8 bhyve: Add raw tcp to uart backend

show more ...


Revision tags: release/13.4.0
# 1f903953 10-Sep-2024 SHENG-YI HONG <aokblast@FreeBSD.org>

bhyve: Add raw tcp to uart backend

This feature is required by OpenStack Nova that needs a serial output
through tcp socket. When enable this feature, a tcp server will be
started and wait for conne

bhyve: Add raw tcp to uart backend

This feature is required by OpenStack Nova that needs a serial output
through tcp socket. When enable this feature, a tcp server will be
started and wait for connection on specified port under capsicum's protection.
We only accept one connection at the same time. Other connection try to
connect will fail.

Reviewed by: corvink, markj
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D45120

show more ...


Revision tags: release/14.1.0
# e10b9d66 01-May-2024 SHENG-YI HONG <aokblast@FreeBSD.org>

bhyve: Move lock of uart frontend to uart backend

Currently, lock of uart in bhyve is placed in frontend. There are some
problems about it:

1. If every frontend should has a lock, why not move it i

bhyve: Move lock of uart frontend to uart backend

Currently, lock of uart in bhyve is placed in frontend. There are some
problems about it:

1. If every frontend should has a lock, why not move it inside backend
as they all have same uart_softc.
2. If backend needs to modify the information of uart after initialize,
it will be impossible as backend cannot use lock. For example, if we
want implement a telnet support for uart in backend, It should wait
for connection when initialize. After some remote process connect it,
it needs to modify rfd and wfd in backend.

So I decide to move it to backend.

Reviewed by: corvink, jhb, markj
Differential Revision: https://reviews.freebsd.org/D44947

show more ...


# d1c5d0cf 21-Mar-2024 Mark Johnston <markj@FreeBSD.org>

bhyve: Move device model-independent UART code into a separate file

Currently bhyve implements a ns16550-compatible UART in uart_emul.c.
This file also contains generic code to manage RX FIFOs and t

bhyve: Move device model-independent UART code into a separate file

Currently bhyve implements a ns16550-compatible UART in uart_emul.c.
This file also contains generic code to manage RX FIFOs and to handle
reading from and writing to a TTY. bhyve instantiates UARTs to
implement COM devices (via pci_lpc.c) and PCI UART devices.

The arm64 port will bring with it a PL011 device model which is used as
the default console (i.e., no COM ports). To simplify its integration,
add a UART "backend" layer which lets UART device models allocate an RX
FIFO and interact with TTYs without duplicating code. In particular,
code in uart_backend.* is to be shared among device models, and the
namespace for uart_emul.* is changed to uart_ns16550_*.

This is based on andrew@'s work in
https://github.com/zxombie/freebsd/tree/bhyvearm64 but I've made a
number of changes, particularly with respect to naming and source code
organization.

No functional change intended.

Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40993

show more ...