All of lore.kernel.org
 help / color / mirror / Atom feed
* Regular Plugin
@ 2005-11-16 18:04 Peter van Hardenberg
  2005-11-17 19:56 ` Edward Shishkin
  0 siblings, 1 reply; 2+ messages in thread
From: Peter van Hardenberg @ 2005-11-16 18:04 UTC (permalink / raw)
  To: reiserfs-list

The notion of the regular plugin seems odd to me. It is a seperate plugin type 
with distinct plugins that only serve to refer to "file" plugins (which are 
found in plugin/object.c, not in plugin/file/*.c).

So when I create a new "file" plugin, I cannot use it unless I also create a 
"regular" plugin which serves no purpose except to allow me to create those 
"file"s by storing their ID.

A few words explaining why the "regular" plugin field couldn't have somehow 
storeda "file" plugin would be educational. Also, regular is a rather unclear 
name. Something like "defaultfileplugin" might be easier to deduce, or even 
"defaultchild".

-pvh

-- 
Peter van Hardenberg (pvh@pvh.ca)
Victoria, BC, Canada

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Regular Plugin
  2005-11-16 18:04 Regular Plugin Peter van Hardenberg
@ 2005-11-17 19:56 ` Edward Shishkin
  0 siblings, 0 replies; 2+ messages in thread
From: Edward Shishkin @ 2005-11-17 19:56 UTC (permalink / raw)
  To: Peter van Hardenberg; +Cc: reiserfs-list

Peter van Hardenberg wrote:

>The notion of the regular plugin seems odd to me. It is a seperate plugin type 
>with distinct plugins that only serve to refer to "file" plugins (which are 
>found in plugin/object.c, not in plugin/file/*.c).
>  
>

In accordance with the last policy file plugins, that implement objects 
which are known
(for vfs) as regular files, should be stored in plugin/file directory, 
so in the latest versions
of reiser4 the file regular.c has been moved to the upper common 
directory "plugin".

>So when I create a new "file" plugin, I cannot use it unless I also create a 
>"regular" plugin which serves no purpose except to allow me to create those 
>"file"s by storing their ID. 
>  
>

You are right.

>A few words explaining why the "regular" plugin field couldn't have somehow 
>storeda "file" plugin would be educational. 
>

Because changing a file plugin id is unsafe operation (at least in the 
case when there is
more then one field of file plugin type in struct plugin_set): suppose 
you allow a some
file plugin to be changed, it means that users also will be able to 
change foo/..../plugin/file,
the main plugin which manages the file "foo". This is why we added a 
special plugin type:
feel free to change these plugins.

>Also, regular is a rather unclear 
>name. Something like "defaultfileplugin" might be easier to deduce, or even 
>"defaultchild".
>
>  
>

Perhaps you are right about clearness, but the reason for the name 
"regular" was the need for
nominated children to be "regular files for vfs". This is why 
"defaultfileplugin" sounds not
so good (file plugin can be a directory file plugin, whereas mkdir 
doesnt look at this field
at all, and "default" sounds like something that is not to be modified). 
Maybe "regularchild"
will improve the situation?

Thanks,
Edward.

>-pvh
>
>  
>


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-11-17 19:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-16 18:04 Regular Plugin Peter van Hardenberg
2005-11-17 19:56 ` Edward Shishkin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.