Hello folks,
here's the first version of my "srvfs" implementation - a synthentic
filesystem which allows a process to "publish" an open file descriptor
into the file system, so other processes can continue from there, with
whatever state the fd is already in.
This is a concept from Plan9. The main purpose is allowing applications
"dialing" some connection, do initial handshakes (eg. authentication)
and then publish the connection to other applications, that now can now
make use of the already dialed connection.
I'm currently developing it out-of-tree - will convert it to patches,
once it reached a stable state.
https://github.com/metux/linux-srvfs-oot
Some quick background pointers on how it works on Plan9:
http://man.cat-v.org/plan_9/4/exportfs
https://9fans.github.io/plan9port/man/man3/dial.html
have fun,
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[email protected] -- +49-151-27565287
On Fri, Aug 07, 2020 at 01:09:30PM +0200, Enrico Weigelt, metux IT consult wrote:
> Hello folks,
>
>
> here's the first version of my "srvfs" implementation - a synthentic
> filesystem which allows a process to "publish" an open file descriptor
> into the file system, so other processes can continue from there, with
> whatever state the fd is already in.
>
> This is a concept from Plan9. The main purpose is allowing applications
> "dialing" some connection, do initial handshakes (eg. authentication)
> and then publish the connection to other applications, that now can now
> make use of the already dialed connection.
Yeah, but... Linux open() always gets a new struct file instance; how
do you work around that? Some variant of ->atomic_open() API change?
Details, please.
On 07.08.20 18:23, Al Viro wrote:
Hi,
>> This is a concept from Plan9. The main purpose is allowing applications
>> "dialing" some connection, do initial handshakes (eg. authentication)
>> and then publish the connection to other applications, that now can now
>> make use of the already dialed connection.
>
> Yeah, but... Linux open() always gets a new struct file instance;
I know :(
> how
> do you work around that? Some variant of ->atomic_open() API change?
> Details, please.
Proxy struct file. Yes, this adds lots of bloat :(
https://github.com/metux/linux-srvfs-oot/blob/master/kernel/proxy.c
I thought about some possible ugly tricks of copying over one into
another, but that could easily end up in a desaster.
Another idea would be adding a new fs-op that returns it's own struct
file - basically kinda per-fs open() syscall - which is called instead
of .open, if defined.
But for now, I tried to implement it as oot-module (and submit for
mainline later), so it could also be used on existing distro kernels.
Maybe that's not the best idea at all :o
What'd be your suggestion ?
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[email protected] -- +49-151-27565287