From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ezOEK-0005KF-R1 for qemu-devel@nongnu.org; Fri, 23 Mar 2018 11:03:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ezOEF-0004z0-W3 for qemu-devel@nongnu.org; Fri, 23 Mar 2018 11:03:44 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:53378 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ezOEF-0004y2-RH for qemu-devel@nongnu.org; Fri, 23 Mar 2018 11:03:39 -0400 References: <1521794165-31678-1-git-send-email-thuth@redhat.com> <6750673e-ffc3-578e-e867-332ac0790935@redhat.com> <173b1d18-720a-4f61-29cf-4f812b78cb2e@redhat.com> From: Paolo Bonzini Message-ID: <8d1b6658-b96c-49c4-563f-9e01e163782e@redhat.com> Date: Fri, 23 Mar 2018 16:03:22 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-2.12] hw/riscv: Fix crashes with "-nodefaults" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Thomas Huth , Michael Clark , QEMU Developers , Bastian Koppelmann , Palmer Dabbelt , Sagar Karandikar , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= 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. >