On (Tue) Apr 20 2010 [13:28:48], Paul Brook wrote: > > It would be useful to have a debugging mode where the chardev layer > deliberately returns spurious EAGAIN and short writes. Otherwise you've got a > lot of very poorly tested device fallback code. I have low confidence in > getting this right first time :-)
Ah, hm, I'll see how I can do that. BTW I test this a couple of ways: 1. make the guest write till the host blocks because the chardev can't accept any more data. I ascertain this during development using some fprintfs. Any more data that gets written fills the guest's vq and then the write() in the guest starts blocking. Once this happens, my testcase succeeds. 2. Send a huge file from the guest to the host and compare the sha1sums at the end of the file transfer. This always results in the chardev returning -eagain a few times (confirm during testing via fprintfs again). The testcase passes if the sha1sums match. The test suite is at http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git Amit
