kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: loris@draios.com (Loris Degioanni)
To: kernelnewbies@lists.kernelnewbies.org
Subject: fd type from number
Date: Tue, 19 Aug 2014 09:34:42 -0700	[thread overview]
Message-ID: <53F37CA2.4000906@draios.com> (raw)
In-Reply-To: <7205.1408464150@turing-police.cc.vt.edu>

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 at vt.edu 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?

  reply	other threads:[~2014-08-19 16:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-19 15:38 fd type from number Loris Degioanni
2014-08-19 15:54 ` Daniel Baluta
2014-08-19 16:02 ` Valdis.Kletnieks at vt.edu
2014-08-19 16:34   ` Loris Degioanni [this message]
2014-08-20  9:33     ` Rohan Puri
2014-08-22 19:03       ` Loris Degioanni
2014-08-23  5:26         ` Rohan Puri
2014-08-19 16:10 ` Greg KH
2014-08-19 16:36   ` Loris Degioanni
  -- strict thread matches above, loose matches on Subject: below --
2014-08-18 16:25 TCP/UDP Nick Krause
2014-08-18 17:31 ` TCP/UDP Denis Kirjanov
2014-08-18 17:33   ` TCP/UDP Nick Krause
2014-08-18 19:43     ` TCP/UDP Nick Krause
2014-08-19  0:46       ` fd type from number Loris Degioanni
2014-08-19 12:04         ` Greg Freemyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53F37CA2.4000906@draios.com \
    --to=loris@draios.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).