On 7/15/24 10:59 AM, Jens Axboe wrote: >On 7/14/24 8:39 PM, hexue wrote: >>> My stance is still the same - why add all of this junk just to detect a >>> misuse of polled IO? It doesn't make sense to me, it's the very >>> definition of "doctor it hurts when I do this" - don't do it. >>> >>> So unless this has _zero_ overhead or extra code, which obviously isn't >>> possible, or extraordinary arguments exists for why this should be >>> added, I don't see this going anywhere. >> >> Actually, I just want users to know why they got wrong data, just a >> warning of an error, like doctor tell you why you do this will hurt. I >> think it's helpful for users to use tools accurately. and yes, this >> should be as simple as possible, I'll working on it. I'm not sure if I >> made myself clear and make sense to you? > >Certainly agree that that is an issue and a much more worthy reason for >the addition. It's the main reason why -EOPNOTSUPP return would be more >useful, and I'd probably argue the better way then to do it. It may >indeed break existing use cases, but probably only because they are >misconfigured. > >That then means that it'd be saner to do this on the block layer side, >imho, as that's when the queue is resolved anyway, rather than attempt >to hack around this on the issuing side. Implementing it at the block layer is indeed more reasonable, thanks for your affirmation and suggestion, I will look for an appropriate place in the path to perform the check. Thanks.
