On Fri, 29 Jul 2022 19:08:41 +0200 Mário Kuka <k...@cesnet.cz> wrote:
> > Since this is being written to a file, handling partial writes makes little > > sense. The only case where partial write would happen would be if filesystem > > was full. Retrying just adds unnecessary complexity. > > > > If you really want to track this, then add a dropped counter. > > But the file descriptor doesn't have to refer to just a regular file, what > if it's a socket or a pipe or some device? The pcapng documentation doesn't > say anything about any restrictions, so the implementation should be fully > generic. What's the point of a function to write packets to a file > descriptor > where there's a risk that it won't write all the packets or that the > file will > by corrupted due to a partial write and still not even let me know about > it? As pcapng is used in the dpdk application it writes to a file. You could repurpose it to something else, but even a pipe will not give partial writes unless you configure the pipe as non-blocking. Writing to a non-blocking pipe is going to have a load of other problems. This seems like a purely hypothetical case, can't see why it needs to be addressed.
