[RFC][PATCH] discontiguous vterms

[Olof Johansson]

Hollis,

(Apple Mail sent that patch as an octet-stream. You might want to check the MIME type next time.)

These are nothing but nitpicks. Feel free to object to any of them, functionally the patch seems
good to me. :)


Comments:

hvc_get_vterms():   "u32 array[]" will never really be an array: array arguments always get casted
to pointers instead. Defining it as one would be less misleading (u32 *array). No logic would have
to change in the function because of this.


hvc_console_setup(): How about a variable that the return value from hvc_get_vterms() is saved in
and compared to instead? Makes it a little more readable.

Other cleanup: There's a struct called hvc_struct, and an instantiation of the same struct called
hvc_struct. Maybe the instantiation should be renamed to "hvcs" or something similar?


Also, one final suggestion: Right now there's hvc_* functions both in pSeries_lpar.c and hvc.c.
Would it be better to split the namespace to be vterm_* or vty_* in pSeries_lpar instead? This would
also make a distinction between the hvc driver and the vterm hypervisor interface.
vterm_get_vterms() would obviously need to be renamed. :)



-Olof


Hollis Blanchard wrote:
> When drivers/char/hvc_console.c was written, OF presented vterm numbers
> to us as a pair of [vterm base, number of vterms] via the
> /rtas/ibm,termno property. This is no longer the case, and instead we
> must use /vdevice/vty nodes.
>
> This patch separates the hvc_struct index from the vterm numbers, so
> you can have e.g. hvc0 = vterm 0 and hvc1 = vterm 723. (In fact I've
> tested that situation with this patch in a hacked environment.) In
> theory the patch is necessary to handle vterms reported by
> "/vdevice/vty at N" nodes in the device tree, since there is no guarantee
> those vterm numbers will be a contiguous range.
>
> In practice, for us, they probably are contiguous. However,
> transforming a list of vty at N nodes (from find_devices()) into [base,
> number] in hvc_count() is a bit awkward at best, and could end up
> making some assumptions about the order in which OF presents device
> nodes to us. Also, this discontiguous functionality might be useful in
> other environments (e.g. PPC simulators). So hvc_get_vterms() replaces
> hvc_count() to communicate the vterm numbers.
>
> I'd like to check this in, because I believe it will make life easier
> in the future when we may actually have multiple vterms (we don't
> today). And if you want to talk about hotplugging vterms, I think the
> flexibility will help a lot there as well, though it's not certain it
> would be needed. Thoughts? hvc_count() is a very quick read for those
> of you not familar with the problem I'm describing...
>
> --
> Hollis Blanchard
> IBM Linux Technology Center


--
Olof Johansson                                        Office: 4E002/905
pSeries Linux Development                             IBM Systems Group
Email: olof at austin.ibm.com                          Phone: 512-838-9858
All opinions are my own and not those of IBM


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/