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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.05.12 at 15:27, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> 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.

That'll be on top of the other post-4.2 changes I'm in the process
of piling up, as this isn't really a bug fix.

Jan


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