[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 08/10] xen/arm: vpl011: Modify the APIs in xenconsole to acces both PV and VCON consoles
Hi Wei Liu, Thanks for your comments. On 12 April 2017 at 22:03, Wei Liu <wei.liu2@xxxxxxxxxx> wrote: > On Mon, Apr 03, 2017 at 03:14:31PM +0530, Bhupinder Thakur wrote: >> Xenconsole supports only PV console currently. To get access to emulated >> pl011 >> uart another backend console is required. >> >> This patch modifies different data structures and APIs used >> in xenconsole to support two console types: PV and VCON (virtual console). >> >> Change summary: >> >> 1. Modify the domain structure to support two console types: PV and a >> virtual console (VCON). >> >> 2. Modify different APIs such as buffer_append() to take a new parameter >> console_type as input and operate on the data structures indexed by >> the console_type. >> >> 3. Modfications in domain_create_ring(): >> - Bind to the vpl011 event channel obtained from the xen store as a >> new >> parameter >> - Map the PFN to its address space to be used as IN/OUT ring >> buffers. >> It obtains the PFN from the xen store as a new parameter >> >> 4. Modifications in handle_ring_read() to handle both PV and VCON >> events. >> >> 5. Add a new log_file for VCON console logs. >> > > It seems that this patch and previous one should be merged into one. > Yes I have merged this patch with the earlier one to maintain the bisectability. > There are a lot of coding style issues, please fix all of them. > I will fix the coding style issues. > The code looks rather repetitive unfortunately. I believe a lot of the > repetitiveness can be avoided by using loops and pointers. > Stefano suggested to define an array of a console structure instead of using different arrays for console related fields in the domain structure. I think that way the changes to the code will be much cleaner. I will incorporate those changes. >> static void domain_close_tty(struct domain *dom) >> { >> - if (dom->master_fd != -1) { >> - close(dom->master_fd); >> - dom->master_fd = -1; >> + if (dom->master_fd[CONSOLE_TYPE_PV] != -1) { >> + close(dom->master_fd[CONSOLE_TYPE_PV]); >> + dom->master_fd[CONSOLE_TYPE_PV] = -1; >> + } >> + >> + if (dom->slave_fd[CONSOLE_TYPE_PV] != -1) { >> + close(dom->slave_fd[CONSOLE_TYPE_PV]); >> + dom->slave_fd[CONSOLE_TYPE_PV] = -1; >> + } >> + >> + if (dom->master_fd[CONSOLE_TYPE_VCON] != -1) { >> + close(dom->master_fd[CONSOLE_TYPE_VCON]); >> + dom->master_fd[CONSOLE_TYPE_VCON] = -1; >> } >> >> - if (dom->slave_fd != -1) { >> - close(dom->slave_fd); >> - dom->slave_fd = -1; >> + if (dom->slave_fd[CONSOLE_TYPE_VCON] != -1) { >> + close(dom->slave_fd[CONSOLE_TYPE_VCON]); >> + dom->slave_fd[CONSOLE_TYPE_VCON] = -1; >> } > > You can use two loops to avoid repetitive snippets. But I'm fine with > the code as-is, too. I have added a new function console_close_tty() which is called for both pv and vuart consoles. The console is abstracted as a separate structure. static void console_close_tty(struct console *con) { if (con->master_fd != -1) { close(con->master_fd); con->master_fd = -1; } if (con->slave_fd != -1) { close(con->slave_fd); con->slave_fd = -1; } } Other functions such as buffer_append(), handle_tty_read() will also operate on the console structure. >> @@ -1166,6 +1346,16 @@ void handle_io(void) >> >> for (d = dom_head; d; d = n) { >> n = d->next; >> + >> + /* >> + * Check if the data pending flag is set for any of >> the consoles. >> + * If yes then service those first. >> + */ >> + if ( d->console_data_pending & (1<<CONSOLE_TYPE_PV) ) >> + buffer_append(d, CONSOLE_TYPE_PV); >> + else if ( d->console_data_pending & >> (1<<CONSOLE_TYPE_VCON) ) >> + buffer_append(d, CONSOLE_TYPE_VCON); >> + > > Why? You seem to have skipped the ratelimit check here. I have thought about this change and I think this check is not required. The rate limit check will ensure that more data is not appended to the buffer as it will keep the events masked and handle_ring_read() will not be called. I will remove this check. Regards, Bhupinder _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |