From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: reiser4 plugins Date: Fri, 24 Jun 2005 01:23:08 -0700 Message-ID: <42BBC2EC.2080000@namesys.com> References: <200506231924.j5NJOvLA031008@laptop11.inf.utfsm.cl> <42BB31E9.50805@slaphack.com> <1119570225.18655.75.camel@localhost.localdomain> <42BB5E1A.70903@namesys.com> <42BB7083.2070107@cisco.com> <42BBAD0F.2040802@namesys.com> <42BBB1FA.7070400@cisco.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <42BBB1FA.7070400@cisco.com> List-Id: Content-Type: text/plain; charset="us-ascii" To: Lincoln Dale Cc: Alan Cox , David Masover , Horst von Brand , Jeff Garzik , Christoph Hellwig , Andrew Morton , Linux Kernel Mailing List , ReiserFS List Lincoln Dale wrote: > >> Now, if his target is reduced to whether we can eliminate a function >> indirection, and whether we can review the code together and see if it >> is easy to extend plugins and pluginids to other filesystems by finding >> places to make it more generic and accepting of per filesystem plugins, >> especially if it is not tied to going into 2.6.13, well, that is the >> conversation I would have liked to have had. >> >> >> > fantastic - some common ground. > any reason WHY there has to be an abstraction of 'pluginid' when in > theory VFS operations can already provide the necessary abstraction on > a per-object basis? VFS supplies instances, plugins are classes. If a language can instantiate an object, that does not eliminate the value of being able to create classes. Does it make sense to you now?