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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.05.12 at 10:25, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 04/05/2012 09:18, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> does this really need to be a per-CPU variable? Can't a timer run only
>> once at a time on the entire system (the more that it gets re-armed only
>> at the end of the poll function, whereas the variable is consumed at the
>> start), and hence the variable can be a simple one? Or else, what
>> subtlety am I overlooking?
> 
> We set up a timer per initialised uart. There can be more than one (although
> granted it is rare).

Is that actually useful? console.c can't really use more than one at a
time (for there being a single sercon_handle), so perhaps it would be
a good thing to avoid the setup for those that aren't actively used,
e.g. by not calling ->init_postirq() for other than the used one?

Oh, wait, with crash_debug there can be a second call to
serial_parse_handle(), so in that case serial console and gdb stub
may run through different ports. With crash_debug off by default,
wouldn't it make sense to optimize for that common case, so that
specifying both "com1=" and "com2=" on the command line wouldn't
needlessly consume resources (as serial_parse_handle() can easily
tag which ports it got called for)? Or would you rather take the
position of expecting people to remove unnecessary command line
options, or live with them having side effects?

Jan


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