On Mon, Apr 30, 2012 at 10:26:03PM +0100, Alan Cox wrote: > > If a read() is interrupted by a signal after it has successfully read > > some data, it shall return the number of bytes read." > > Fair point - I guess technically EFAULT is not a signal. I still think > its a better behaviour to not lose bytes but objection withdrawn. I generally agree (with other errors that are not due to faulty application implementation). But I think signalling EFAULT is more beneficial than partial read, because it will let application know earlier that it uses incorrcet buffers. If we were to return patrtial success apllication would simply retry the read and would never even know that there is a problem. Another is practical consideration in serio_raw - we take bytes out of the queue and then attempt to put_user(). If it faults and we decide to return partial success we need to put the byte we just fecthed back into the queue. Or we can see if memory can be accessed before fetching the byte. In both cases we make the driver more complex for benefit of faulty applications. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
