From: Thomas Graf <tgraf@suug.ch>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
stephen@networkplumber.org, ast@plumgrid.com, jiri@resnulli.us,
netdev@vger.kernel.org, Jamal Hadi Salim <jhs@mojatatu.com>
Subject: Re: [PATCH iproute2 -next] tc, bpf: finalize eBPF support for cls and act front-end
Date: Thu, 2 Apr 2015 13:10:03 +0100 [thread overview]
Message-ID: <20150402121003.GA21588@casper.infradead.org> (raw)
In-Reply-To: <1427974255.2093319.248499373.05D36231@webmail.messagingengine.com>
On 04/02/15 at 01:30pm, Hannes Frederic Sowa wrote:
> On Thu, Apr 2, 2015, at 12:19, Daniel Borkmann wrote:
> > I'm probably missing something, would that need changes to bash?
> >
> > I mean exec could bind an fd in the shell to sockets and use that,
> > for example ...
> >
> > exec 3<>/dev/tcp/www.slashdot.org/80
> > echo -e "GET / HTTP/1.1\r\nhost:
> > http://www.slashdot.org\r\nConnection: close\r\n\r\n" >&3
> > cat <&3
> >
> > ... perhaps such a built-in fake device for retrieving bpf map fds
> > might be interesting, e.g. exec 4<>/dev/bpf/<obj-file>/<map-name> if
> > that has been given to bash?
> >
> > Anyway, I think to have some utility for shell scripts, as you
> > suggest, certainly sounds interesting!
>
> All file descriptors will be inherited by exec as long as the O_CLOEXEC
> flag wasn't specified on them. So you can retrieve the fds via af_unix
> and just exec a new shell. The file descriptors will stay open and you
> can pass the numbers of the fds via environment. This wouldn't need
> changes to bash or kernel.
We also have to consider implementing a way to reopen the fds after
the original process has crashed but I agree this is a great start
for the tc environment.
prev parent reply other threads:[~2015-04-02 12:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 22:35 [PATCH iproute2 -next] tc, bpf: finalize eBPF support for cls and act front-end Daniel Borkmann
2015-04-01 5:16 ` Alexei Starovoitov
2015-04-01 8:48 ` Daniel Borkmann
2015-04-01 12:36 ` Jamal Hadi Salim
2015-04-01 14:13 ` Daniel Borkmann
2015-04-01 22:30 ` Thomas Graf
2015-04-08 11:58 ` Jamal Hadi Salim
2015-04-02 0:13 ` Hannes Frederic Sowa
2015-04-02 0:24 ` Daniel Borkmann
2015-04-02 0:29 ` Hannes Frederic Sowa
2015-04-02 10:19 ` Daniel Borkmann
2015-04-02 11:30 ` Hannes Frederic Sowa
2015-04-02 12:08 ` Daniel Borkmann
2015-04-02 16:14 ` Alexei Starovoitov
2015-04-02 18:38 ` Daniel Borkmann
2015-04-02 12:10 ` Thomas Graf [this message]
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=20150402121003.GA21588@casper.infradead.org \
--to=tgraf@suug.ch \
--cc=ast@plumgrid.com \
--cc=daniel@iogearbox.net \
--cc=hannes@stressinduktion.org \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.