linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <info@metux.net>
To: linux-kernel@vger.kernel.org
Cc: viro@zeniv.linux.org.uk, info@metux.net, keescook@chromium.org,
	anton@enomsg.org, ccross@android.com, tony.luck@intel.com,
	linux-fsdevel@vger.kernel.org
Subject: RFC: allow recording and passing of open file descriptors
Date: Tue, 29 Jun 2021 16:43:39 +0200	[thread overview]
Message-ID: <20210629144341.14313-1-info@metux.net> (raw)

Hello folks,


here's an attempt to make it to record open file descriptors (struct file*)
and make them available to other processes via file system. The semantics
are similar to dup() or passing via Unix socket in regard that the 
receiving process will get reference to the same struct file instance into
its fdtable. But the big difference here is we're doing it directly via
file system (ie. retrieving is done by a simple open()). It works pretty
much like like Plan9's /srv file system:

    http://man.cat-v.org/plan_9/3/srv

To archive that, the first patch introduces the concept of "file boxing",
which means an open file operation can put a reference to another file
into the struct file, which will then be returned to the caller, instead
of the newly created one. The reason for doing it this strange way is that
the new struct file instance is allocated and prepared very early, before
we're calling into the actual file operation - refactoring this so that
the open() file op directly returns a struct file* pointer would be a
massively intrusive change, that I just don't dare to do here.

The second patch introduces a new file system "srvfs" that works like
Plan9's /srv file systems.


Another use case for the first patch could be direct fd passing in FUSE,
like Peng Tao and Alessio Balsini are currently working on, via other means.

    https://www.spinics.net/lists/linux-fsdevel/msg196163.html


I believe the patch 1 should be pretty straightforward and not doing any harm.
(it's not even compiled in unless explicitly enabled by something else)


have run,

--mtx

---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287


             reply	other threads:[~2021-06-29 14:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-29 14:43 Enrico Weigelt, metux IT consult [this message]
2021-06-29 14:43 ` [RFC PATCH 1/2] fs: allow filesystems to directly pass an existing struct file Enrico Weigelt, metux IT consult
2021-06-29 14:43 ` [RFC PATCH 2/2] fs: srvfs: new pseudo-fs for publishing opened fd's in the filesystem Enrico Weigelt, metux IT consult

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=20210629144341.14313-1-info@metux.net \
    --to=info@metux.net \
    --cc=anton@enomsg.org \
    --cc=ccross@android.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=viro@zeniv.linux.org.uk \
    /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).