Sure, here's some more context. I'm one of the developers of sysdig (www.sysdig.org), a tool that captures system calls and uses them to offer advanced system monitoring. One of the features that our diver offers is the tcpdump-derived concept of "snaplen": when a system call with a buffer is captured, it's possible to choose how many bytes of that buffer are copied to the driver capture buffer. This makes it possible to tune buffer utilization and CPU usage vs completeness of data. Since this feature is important and heavily used, I'd like to extend it so that the user has per-fd-type snaplen control. A typical use case is: "I want 1000 bytes of each socket buffer, because I'm interested in looking at protocol activity, but I don't care about files and so I'm ok with just 20 bytes from them". In order for this feature to be useful, it needs to be very fast: we use tracepoints to capture system calls, so we slow down the original process if we take too long. And since I'm here, let me expand my question. Another useful thing to do would be per-filename snaplen. Use case: "I want the whole content of reads and writes to files that are in /etc, but I want only 20 bytes from any other system call". This would I guess involve unpacking the file structure and retrieving the full file name. Is there any way to do it safely and efficiently? Thanks, Loris On 8/19/2014 9:02 AM, Valdis.Kletnieks@xxxxxx wrote: > On Tue, 19 Aug 2014 08:38:24 -0700, Loris Degioanni said: > >> I'm looking for an efficient way to determine the type of an fd (file, >> socket...) given its number, from a kernel module. > What problem are you trying to solve here? There may be a better API for > your problem. So step back - what are you trying to accomplish? _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
