>> > One issue with the above proposed change to use TP_STATUS_IN_PROGRESS >> > is that the documentation of the tp_status field is somewhat >> > inconsistent. In some places it's described as TP_STATUS_KERNEL(0) >> > meaning the entry is owned by the kernel and !TP_STATUS_KERNEL(0) >> > meaning the entry is owned by user space. In other places ownership >> > by user space is defined by the TP_STATUS_USER(1) bit being set. >> >> But indeed this example in packet_mmap.txt is problematic >> >> if (status == TP_STATUS_KERNEL) >> retval = poll(&pfd, 1, timeout); >> >> It does not really matter whether the docs are possibly inconsistent and >> which one is authoritative. Examples like the above make it likely that >> some user code expects such code to work. > > Yes, that's exactly my concern. Yet another troubling example seems to be > lipbcap which also is looking specifically for status to be anything other > than > TP_STATUS_KERNEL(0) to indicate a frame is available in user space.
Good catch. If pcap-linux.c relies on this then the status field cannot be changed. Other fields can be modified freely while tp_status remains 0, perhaps that's an option.