On Mon, 2 Jun 2008, Ben Dooks wrote: > makes reporting the amount of data written difficult, how do you > indicate I wrote m bytes, got an error, and then continued on to > write all n bytes of the i2c_msgs provided? Can anyone think of > an actual example of where this would be useful?
Useful enough that someone would actually write the code to use it? No. > Yes, that does make sense to return the amount of data written to > the user, however having a quick look through all users of > i2c_transfer() all just want to know if all the messages where > sent (which is an easier check that to compute the amount of > data in all the messages). > > Would it better to add an new i2c_transfer-alike call which would > return the amount of data written, instead of going around modifying > all users of i2c_transfer() ? This would also make transfering from > one call to the other, with i2c_transfer becoming deprecated? My experience with I2C drivers is the same. No one cares how many bytes were written before a NAK, they're just going to take same failure path no matter what (assuming they even check for an error at all). I think it's enough to document the interface can't provide this information, and if someone does have a real use for it in the future, let them add support when the time comes. There's no point in creating an interface that no one is going to use. _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
