Re: [Xen-devel] ns16550.c's poll_port variable

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.05.12 at 14:03, Keir Fraser <keir@xxxxxxx> wrote:
> On 04/05/2012 12:05, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>>> I'm unclear on exactly what you want to optimise away? Certainly the 8 bytes
>>> per CPU of the poll_port variable isn't worth much optimising effort.
>> 
>> Certainly not (and as you say they are actually needed, even if
>> only rarely). But the pointlessly running timer(s) might be, as might
>> the buffer(s) set up via serial_async_transmit().
> 
> We could delay {init,setup}_postirq until a corresponding serial handle has
> been created via serial_parse_handle()? The logic might be a bit ugly and
> spread across both serial.c and ns16550.c but not actually particularly
> complicated?

I think this can be done entirely in serial.c - serial_init_postirq()
would directly call any drivers that already got a handle parsed
for them, and serial_parse_handle() would need to call
->init_postirq() for any driver that didn't have it called already.
serial_suspend() and serial_resume() should then call drivers only
if they previously had ->init_postirq() called.

I definitely want to avoid putting any part of this into ns16550.c,
as it would need to be replicated for ARM's pl011.c as well as any
future ones (I'm now mostly done with an EHCI debug port driver,
but due to feature freeze won't be able to post this as other than
an RFC any time soon; xHCI appears to also have a debug port,
so in the future that might become a third alternative).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel