On 05/03/2012 05:07 PM, Pekka Enberg wrote: > On Thu, May 3, 2012 at 10:57 AM, Minchan Kim <minchan@xxxxxxxxxx> wrote: >> Sorry for my poor explanation. >> My point is when userspace get vmevent_event by reading fd, it could enumerate >> several attribute all at once. >> Then, one of attribute(call A) made by vmevent_match in kernel and other attributes(call B, C, D) >> are just extra for convenience. Because there is time gap when kernel get attribute values, B,C,D could be stale. >> Then, how can user determine which event is really triggered? A or B or C or D? >> Which event really happens? > > Right. Mark the matching values with something like > VMEVENT_ATTR_STATE_CAPTURED should be sufficient? Seems to be good and we have to notice to user by document "Except VMEVENT_ATTR_STATE_CAPTURED, all attributes's value could be stale. So, don't be deceived. Please ignore if you need" First of all, let make CAPTURED state could be exact. ----- > Q 2. Is it okay although value when vmevent_match check happens is different with > vmevent_sample_attr in vmevent_sample's for loop? > I think it's not good. Yeah, that's just silly and needs fixing. ----- > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@xxxxxxxxx. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ > Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a> > -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>