On Sun, 5 Jul 2026 at 23:05, Philippe Mathieu-Daudé <[email protected]> wrote: > > On 4/7/26 03:41, Yanfeng Liu wrote: > > > > Philippe, > > > > The v1 always creates UART1 carelessly, then Peter suggested following > > 5d8a250f9068 (openrisc) and e7100972f2 (arm) to reduce guest breakage. > > Oh I missed that. I'm confused because I thought not checking for > backend use of a chardev (in particular calling serial_hd) was part > of Peter's recommendations, since he did that cleanup years ago.
Where we're modelling a real piece of hardware that always has, say, two UARTs, we want to always create both UARTs (because they're always there in the real hardware, whether there's a serial cable plugged into them or not). Having the chardev code handle "backend is NULL" as equivalent to "this is the do-nothing backend" lets us avoid unnecessary conditionals in the board code. For "virtual" board types where it's QEMU defining what they are, the situation is a little different. Ideally we'd do the simple thing, i.e. "just create all the devices", but where there's existing guest software that makes assumptions about how older versions of QEMU used to behave and the number of users of the board type is big enough that we care about not breaking that, we sometimes need to do something else. The "only create the second UART if the user puts another -serial option on the command line" was the best idea I could come up with for letting the user opt into the extra functionality if they needed it. (If we have another future architecture that creates a "virt" board type we should make sure we have it create at least two UARTs right from the beginning, because we've now made this mistake twice :-)) -- PMM
