Re: Regular Plugin

[Edward Shishkin <edward@namesys.com>]

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
>
>  
>