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

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 04/05/2012 13:46, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

>>>> 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.

Ah yes, that would work. Feel free to make a patch.

 -- Keir

> 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