On Thu, Mar 17, 2011 at 08:50:33PM -0400, Andy Walls wrote: > On Thu, 2011-03-17 at 15:08 -0400, Jarod Wilson wrote: > > On Thu, Mar 17, 2011 at 12:16:31PM -0400, Andy Walls wrote: > > > Jarod Wilson <jarod@xxxxxxxxxx> wrote: > > . > > > > > > But the orignal intent of the check I put in was to avoid passing > > partial/junk data to userspace, and go around again to see if good > > data could be provided. > > > > > > Your check bails when good data that might be sitting there still. > > That doesn't seem like a good trade for supporting backward compat for > > old kernels. > > > > Ah. Another thing I neglected to notice then. :) > > > > Perhaps there should be a retry count check as well then, as otherwise, > > its possible to get stuck in that loop forever (which is what was > > happening on older kernels). Its conceivable that similar could happen on > > a newer kernel for some reason. > > Well, lets see, > > >From the perspective of userspace & lircd: > > 1. A specification compliance failure for a corner case isn't too bad > (bailing out on junk and leaving good data behind) > > 2. An unrecoverable failure for any case is very bad (spinning/hanging > on a result that won't change) > > 3. Sending unitialized bytes out to userspace with copy_to_user() is > very bad. > (I recall the old code would do the copy to user and always tell > userspace it got a code whether it read anything out of the buffer or > not. IIRC, that leaked information off the stack.) > > > If the code as patched avoids the two very bad things (#2 and #3), then > the patch is OK by me. I *think* what I've got now should address both 2 and 3, with a very minimal risk of leaving data behind, since it'll retry a couple of times before bailing out of the loop, so it should be pretty unlikely we'd leave any good data behind. But even if we do, like you said, this is just an IR signal, the user can press the button on the remote again. :) -- Jarod Wilson jarod@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
