linux-kernel - Re: [V9fs-developer] [PATCH] 9p: create separate 9p client interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 30 Apr 2007 11:30:29 -0500
From:	"Eric Van Hensbergen" <ericvh@...il.com>
To:	"Christoph Hellwig" <hch@...radead.org>,
	"Latchesar Ionkov" <lionkov@...il.com>,
	"Andrew Morton" <akpm@...l.org>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>,
	"V9FS Developers" <v9fs-developer@...ts.sourceforge.net>
Subject: Re: [V9fs-developer] [PATCH] 9p: create separate 9p client interface

On 4/30/07, Christoph Hellwig <hch@...radead.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.
>

I'll let Lucho give more details on his possible uses for such an
interface -- for my part we have been looking at doing in-kernel
servers for more efficient export of devices and system services (such
as the network stack).  We've been using user space applications for
doing such sharing, but there are undesirable inefficiencies in such
an approach.

>>19 files changed, 1656 insertions(+), 1585 deletions(-)

I believe the log message was poorly worded, it was more of a
reorganization of the existing interface versus the creation of an
additional interface.

>
> Also the non-filesystem interface code shouldn't live in fs/ but
> rather in net/9p/
>

Which bits do you think are candidates for such a move?  The transport
interfaces? (there are a few more in the wings to cover shared memory
transports for VMMs among other things)  Should the protocol elements
move as well? -- that seems a bit fuzzier to me.

            -eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/