Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device

[Janosch Frank]

[...]
>>>>> The main problem here is that you want to exercise a middle layer (the
>>>>> css code) and need to write boilerplate code on both host and guest
>>>>> side in order to be able to do so.
>>>>>     
>>>>
>>>> Nod.
>>>>  
>>>>> In general, a device that accepts arbitrary channel programs looks
>>>>> useful for testing purposes. I would split out processing of expected
>>>>> responses out, though, so that it can be more easily reused for
>>>>> different use cases.
>>>>>     
>>>>
>>>> I'm not sure what do you mean here. Could you clarify please?  
>>>
>>> Maybe doing things like logging received ccws and responses etc. and
>>> and then comparing against an expected outcome. You should be able to
>>> write test cases for different sets of things to be tested. I know this
>>> is awfully vague :)  
>>
>> Yes it does sound awfully vague :). In my case different tests are
>> actually done in the kernel module implementing a driver for this
>> device. I compare the expected outcome and the actual outcome there.
>> This device is just a back-end lending itself to experimentation.
> 
> I think we want both guest-side and host-side checking. I think we
> should aim for a guest-side checker that does not require a kernel
> module (a simple guest makes it easier to run as an automated test.)

Sure, that would be great.

The thing is that I want to test the subchannel and not the device and
therefore I really do not want to have to issue control commands to a
device in order to get data. Having a device that reads and writes
without a lot of overhead (like this) is therefore my main target.

Where this device lives doesn't concern me and as I'm new to this
wonderful IO system take my statements with some salt. :)


>>>>> For the guest tester: Can that be done via the qtest infrastructure
>>>>> somehow?
>>>>>     
>>>>
>>>> Well, for now I have the out-of-tree Linux kernel module provided in the
>>>> cover letter of the series (you did not comment on that one yet).  
>>>
>>> Yes, I saw that, but have not yet looked at it. If there is a way to do
>>> it without too many extra parts, I'd prefer that.
>>>   
>>
>> Well, I think the module is almost as economical with extra parts as it
>> can get: it uses the kernel infrastructure and does not do a whole lot
>> of things on top.
> 
> And that's also the problem: You drag the whole kernel infrastructure
> along with i
> 
>>
>> I think it's worth a look.
> 
> It certainly is, but you know how it is with resources...

Yes it is and we certainly want to be integrated in as much external
testing as possible. It seems like a few people began to run into the
same direction but chose different approaches. My zonk test intentions
are mainly to get a understanding how this all works without having to
use the Linux devices but getting my hands dirty with the instructions
and structures.

I see your arguments and we'll look into it and discuss consolidating
our efforts.

signature.asc
Description: OpenPGP digital signature