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