HuangZhen said, flush: flush has been add to the new version of lrm_api.h, please refer to Issue 16. drain: would you like to explain why we need drain? the question: according to current design, there is no automatic flush.
AlanRobertson replies: This is exactly why an automatic flush of existing, but not executed operations might be desirable. The problem is that you only return the status of the last command, and also the next commands on the operation might not be appropriate if an operation in the queue failed first. This is the kind of thing that disk device drivers and others that queue commands do. But, no one has decided whether this should happen. This is really just a comment at this point, sort of a reminder that we need to make a decision on what the right thing to do is.
AlanRobertson continues on about drain(). This is another type of operation which is common when command queueing is present. The purpose of a drain operation is that one might want to know when all existing operations on a particular resource are completed. The drain operation completes when all the operations in the queue (regardless of how many there are and where the came from) complete. As was mentioned before, this is not something which had been decided is a requirement. It's a reminder to Andrew to decide for sure, and then if he says yes, we can go ahead and do it. It would probably be important that the drain operation not change the last command executed or last command return code.
LarsMarowskyBree adds that an automatic flush() on failure seems to be desirable. It is not mandatory though. A drain() however seems not to be needed, given that we have get_cur_state() and flush(). But it sure wouldn't hurt either, we may just not end up using it. It remains to be defined if a drain() would also cancel any pending monitor operations (as flush() likely should too)? My gut feeling is that it should.
AlanRobertson clarifies some more. A drain() operation can only be approximated by a status operation. However, it is not a perfect approximation, since it clears the last operation state. The point of a drain operation is not error recovery but determination of status, so IMHO, it should not meddle with anything else like cancel current monitor operations (like a flush would). Another way to add a drain which might be more useful would be to add an immediate/queued parameter to the get_cur_state() operation. Given that we aren't actually doing anything much to our resources, IMHO many of the other traditional operations like suspend and resuming queues, and giving immediate (unqueued) operations would be overkill here.
AndrewBeekhof chips in. I'm thinking that neither drain() nor flush() should cancel the monitor op. As I see it, the intention of both functions is to (help) determin the most up-to-date information for a resource - stopping the monitor op goes against this purpose (or at least the purpose I had in mind). However I can see that if any action fails, it would be nice if the monitor stopped so it doesnt overwrite the last action & result information.
AndrewBeekhof rambles on... as for drain() vs. flush(), I think having flush() and a get_cur_state() that had an immediate/queued parameter would do very nicely thankyou