From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Zarochentsev Subject: Re: reiser4 plugins Date: Thu, 23 Jun 2005 21:31:32 +0400 Message-ID: <200506232131.33468.zam@namesys.com> References: <20050620235458.5b437274.akpm@osdl.org> <200506221824.32995.zam@namesys.com> <20050622142947.GA26993@infradead.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary-00=_1HvuC/bA8khzsro" Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <20050622142947.GA26993@infradead.org> Content-Disposition: inline List-Id: To: Christoph Hellwig Cc: reiserfs-list@namesys.com, Hans Reiser , Andrew Morton , linux-kernel@vger.kernel.org --Boundary-00=_1HvuC/bA8khzsro Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Wednesday 22 June 2005 18:29, Christoph Hellwig wrote: > On Wed, Jun 22, 2005 at 06:24:32PM +0400, Alexander Zarochentsev wrote: > > Reiser plugins are for the same. Would you agree with reiser4 plugin > > design if the plugins will not dispatch VFS object methods calls by > > themselves but set ->foo_ops fileds instead? I guess you don't like to > > have the two dispatching systems at the same level. > > That is exactly the point I want to make. I haven't looked at the design > in detail for a long time, but schemes to allow different object to have > different operation vectors is a good idea. By same level i meant the vfs-like portion of reiser4 object plugin (read/write/readdir ...). The rest of plugin can't be done by VFS, it is about reiser4-specific things. The way how vfs calls are passed to reiser4 objects can be re-written to use VFS features by 100% but i don't think it woild make the code better. What is done currently is 1) reduces places when VFS enters reiser4 -- better because each VFS method implementation needs at least reiser4 context initialization/destroying; 2) uses existing reiser4 plugin scheme -- it adds no complexity because reiser4 can't live without plugins. Can we leave the plugins as they are? > We already have that to > varying degrees in all filesystems, and making that more formal is a good > thing. Thanks, Alex. --Boundary-00=_1HvuC/bA8khzsro Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

On Wednesday 22 June 2005 18:29, Christoph Hellwig wrote:

> On Wed, Jun 22, 2005 at 06:24:32PM +0400, Alexander Zarochentsev wrote:

> > Reiser plugins are for the same. Would you agree with reiser4 plugin

> > design if the plugins will not dispatch VFS object methods calls by

> > themselves but set ->foo_ops fileds instead? I guess you don't like to

> > have the two dispatching systems at the same level.

>

> That is exactly the point I want to make. I haven't looked at the design

> in detail for a long time, but schemes to allow different object to have

> different operation vectors is a good idea.

By same level i meant the vfs-like portion of reiser4 object plugin (read/write/readdir ...). The rest of plugin can't be done by VFS, it is about reiser4-specific things. The way how vfs calls are passed to reiser4 objects can be re-written to use VFS features by 100% but i don't think it woild make the code better.

What is done currently is 1) reduces places when VFS enters reiser4 -- better because each VFS method implementation needs at least reiser4 context initialization/destroying; 2) uses existing reiser4 plugin scheme -- it adds no complexity because reiser4 can't live without plugins.

Can we leave the plugins as they are?

> We already have that to

> varying degrees in all filesystems, and making that more formal is a good

> thing.

Thanks,

Alex.

--Boundary-00=_1HvuC/bA8khzsro--