Re: [PATCH v2 2/3] Packet sniffer core framework
From: Stathis Voukelatos
Date: Wed Feb 18 2015 - 11:44:45 EST
On 18/02/15 15:42, Daniel Borkmann wrote:
This whole framework really looks like only tailored to your specific
driver, I have no idea who else should reuse that?! So, I don't think
putting this under drivers/net/pkt-sniffer/ is a good idea.
Yes, it is not necessarilly expected to be used by other 3rd party
drivers. The reason of splitting out the framework code is to account of
the fact the we may develop in the future othersimilar sniffer H/W for
non-ethernet interfaces (eg. wifi).
I can move the code under drivers/net/ethernet/linn as you mention
below, although that may not account for non-ethernet backends in the
Also it looks slightly confusing as if I understand you correctly, your
module's purpose is to pass down some "packet pattern" to the hardware
and match that in order to get a precise timestamp in return?
Yes, this point can be slightly confusing. A write to a packet socket
bound to the interface is done to supply the command string to the
sniffer H/W, while reads would return matched packet bytes + timestamps
(throuch cmsg). Is there any other way to supply the command string
except of a proprietary ioctl?
Might perhaps be better to have everything vendor-specific under something
like drivers/net/ethernet/linn/ and have the framework squashed into the
driver itself (if parts cannot be generalized in net/packet/).
It would be good if you can also avoid the extra uapi export. Perhaps
it's possible to reuse at least some of the existing timestamping
I can remove that. The header file only contains the list of commands.
They can be documented. The driver does use the existing timestamping
infrastructure to return timestamps to user space.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/