On 23/03/2018 15:28, Peter Maydell wrote: >> Note it's a null "backend", not necessarily a null "character device". >> Your proposal, namely ensuring that be->chr == NULL is handled properly >> in qemu_chr_fe_init, would be just fine. > > Hmm, the chardev layer code seems to have more ends than I expect. > The "frontend" is the UART model, right, and I thought the > "backend" was the TCP/UDP/serial port/stdio/etc end of things, > but those seem to be Chardevs? If those aren't the backend, > then what is?
The naming of Chardev/CharBackend was modeled after BlockDriverState/BlockBackend, and it's not great but at least it's consistent. :/ The CharBackend struct essentially connects a Chardev and its user. It ought to be possible for the Chardev to be NULL. Paolo > What I'd like, anyway, is that every UART model can cope with being > setup with a NULL 'chardev' property, and ideally that that doesn't > require a lot of extra code per-UART, and doesn't require each UART > to create a TYPE_CHARDEV_NULL. >
