From: "Latchesar Ionkov" <lucho@ionkov.net>
To: "Christoph Hellwig" <hch@infradead.org>,
"Latchesar Ionkov" <lionkov@gmail.com>,
"Andrew Morton" <akpm@osdl.org>,
"Linux Kernel" <linux-kernel@vger.kernel.org>,
"V9FS Developers" <v9fs-developer@lists.sourceforge.net>
Subject: Re: [PATCH] 9p: create separate 9p client interface
Date: Mon, 30 Apr 2007 11:00:20 -0600 [thread overview]
Message-ID: <f158dc670704301000p27e22637p73ec6654812a54b9@mail.gmail.com> (raw)
In-Reply-To: <20070430161318.GA29321@infradead.org>
Hi,
On 4/30/07, Christoph Hellwig <hch@infradead.org> wrote:
> On Mon, Apr 30, 2007 at 09:32:41AM -0600, Latchesar Ionkov wrote:
> > Create a separate 9P client interface that can be used outside the VFS
> > layer. In addition to VFS, the new interface can be used to export the
> > authentication channel or from other interfaces.
>
> And what exact users would that be? We have a huge dislike for putting
> abstractions in just for the abstractions sake, so if you want this
> merged you'd better present a highly useful client to that interface.
In the current implementation the 9p VFS layer uses directly the
low-level 9p messages. It intermixes the logic required by VFS with
managing some data structures (v9fs_fid for example) that belong to
9P. This makes the VFS code harder to understand and modify.
Separating the low-level 9p interface makes the VFS operations shorter
and easier to understand.
Another scenario that we need separate interface for is exporting the
authentication channels to user space so more than one user can be
authenticated. The work on finishing the authentication will take some
more time, but there are other changes that Eric is working on and
that will also benefit from this change.
The interface that this patch creates is internal to 9p and involves
mainly moving code from the vfs_* files to a separate file. fs/9p is
less than 50 LOC bigger than the previous version.
> Also the non-filesystem interface code shouldn't live in fs/ but
> rather in net/9p/
That makes sense, thanks. I can split the code and put the low-level
transport/multiplexer/9pclient(and eventually Eric can add his
9pserver) in a net/9p directory.
Thanks,
Lucho
next prev parent reply other threads:[~2007-04-30 17:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-30 15:32 Latchesar Ionkov
2007-04-30 16:13 ` Christoph Hellwig
2007-04-30 16:30 ` [V9fs-developer] " Eric Van Hensbergen
2007-04-30 17:00 ` Latchesar Ionkov [this message]
2007-04-30 18:16 ` Jan Engelhardt
2007-04-30 18:22 ` Latchesar Ionkov
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=f158dc670704301000p27e22637p73ec6654812a54b9@mail.gmail.com \
--to=lucho@ionkov.net \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lionkov@gmail.com \
--cc=v9fs-developer@lists.sourceforge.net \
/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
all inboxes | Powered by JetHome®