On 09/05/2017 01:16 PM, Halil Pasic wrote: > Abstract > -------- > > The objective of this series is introducing CCW IDA (indirect data > access) support to our virtual channel subsystem implementation. Briefly > CCW IDA can be thought of as a kind of a scatter gather support for a > single CCW. If certain flags are set, the cda is to be interpreted as an > address to a list which in turn holds further addresses designating the > actual data. Thus the scheme which we are currently using for accessing > CCW payload does not work in general case. Currently there is no > immediate need for proper IDA handling (no use case), but since it IDA is > a non-optional part of the architecture, the only way towards AR > compliance is actually implementing IDA. >
[..] The discussion seems to have settled down quite a bit. Since there weren't many complaints, I would like to opt for a v2 fixing the things pointed out during the review early next week (I was thinking Tuesday maybe some late birds are going to join in). @Connie ======== Does that sound reasonable or would you like more time for v1? What do you think, would it make more sense to omit or to keep the testing stuff for v2 (I mean patch 5 and the kernel module in the cover letter)? You probably haven't found the time to look at have a glance at "s390x/css: drop data-check in interpretation" (http://patchwork.ozlabs.org/patch/810995/). We have said it would make some things more straight forward here, and I could drop that ugly TODO comment. I think it's quite straight-forward, and I would not mind having a decision on it before v2 or putting it as preparation into v2. What do you prefer? Regards, Halil
