* Plugin structure documentation request
@ 2005-12-14 8:33 Peter van Hardenberg
2005-12-14 9:09 ` Hans Reiser
0 siblings, 1 reply; 3+ messages in thread
From: Peter van Hardenberg @ 2005-12-14 8:33 UTC (permalink / raw)
To: reiserfs-list
It would be quite excellent if we could have even a one sentence description
of all the plugin structures. This structure includes many operations not
found in conventional VFS, and many of the calls are not described in any
documentation I have found.
I must confess I am feeling some frustration at the complete lack of
documentation of the project. I have very few complaints about the quality of
the code, but despite having spent four months working through file after
file I still regularly stumble across areas we have not had an excuse to
delve into and have no idea how they work in a general sense or what they do.
This kind of documentation does not take particularly long to generate but
would save new users of the code many, MANY long hours spent poring over code
and tracking function calls through the enormous structure.
I know you have heard it from the kernel mailing list before, but now you are
hearing it from someone uninvolved in that process. A trivial script reports
93866 lines of code in the reiser4 directory. That's a lot of code to
navigate without a map.
Having got that off my chest, here is one example of a plugin struct that
could use documentation. There are several other examples -- notably the
pseudo.c structure which is relatively uncomplicated and the directory plugin
which is about as complicated as this example "file" plugin.
[PSEUDO_FILE_PLUGIN_ID] = {
.h = {
.type_id = REISER4_FILE_PLUGIN_TYPE,
.id = PSEUDO_FILE_PLUGIN_ID,
.pops = &file_plugin_ops,
.label = "pseudo",
.desc = "pseudo file",
.linkage = TYPE_SAFE_LIST_LINK_ZERO
},
.open = open_pseudo,
.truncate = eperm,
.write_sd_by_inode = eperm,
.readpage = eperm,
.capturepage = NULL,
.capture = NULL,
.read = read_pseudo,
.write = write_pseudo,
.release = release_pseudo,
.ioctl = eperm,
.mmap = eperm,
.sync = sync_common,
.get_block = eperm,
.flow_by_inode = NULL,
.key_by_inode = NULL,
.set_plug_in_inode = set_plug_in_inode_common,
.adjust_to_parent = NULL,
.create = NULL,
.delete = eperm,
.add_link = NULL,
.rem_link = NULL,
.owns_item = NULL,
.can_add_link = cannot,
.can_rem_link = cannot,
.setattr = inode_setattr,
.getattr = getattr_common,
.seek = seek_pseudo,
.detach = detach_common,
.bind = bind_common,
.safelink = NULL,
.estimate = {
.create = NULL,
.update = NULL,
.unlink = NULL
},
.wire = {
.write = wire_write_pseudo,
.read = wire_read_pseudo,
.get = wire_get_pseudo,
.size = wire_size_pseudo,
.done = wire_done_pseudo
},
.init_inode_data = NULL,
.pre_delete = NULL,
.cut_tree_worker = cut_tree_worker_common,
.destroy_inode = NULL,
},
Thanks,
-pvh
--
Peter van Hardenberg (pvh@pvh.ca)
Victoria, BC, Canada
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Plugin structure documentation request
2005-12-14 8:33 Plugin structure documentation request Peter van Hardenberg
@ 2005-12-14 9:09 ` Hans Reiser
2005-12-14 11:06 ` Alexander Zarochentsev
0 siblings, 1 reply; 3+ messages in thread
From: Hans Reiser @ 2005-12-14 9:09 UTC (permalink / raw)
To: Peter van Hardenberg; +Cc: reiserfs-list, Alexander Zarochentcev
Peter van Hardenberg wrote:
>It would be quite excellent if we could have even a one sentence description
>of all the plugin structures. This structure includes many operations not
>found in conventional VFS, and many of the calls are not described in any
>documentation I have found.
>
>I must confess I am feeling some frustration at the complete lack of
>documentation of the project. I have very few complaints about the quality of
>the code, but despite having spent four months working through file after
>file I still regularly stumble across areas we have not had an excuse to
>delve into and have no idea how they work in a general sense or what they do.
>This kind of documentation does not take particularly long to generate but
>would save new users of the code many, MANY long hours spent poring over code
>and tracking function calls through the enormous structure.
>
>I know you have heard it from the kernel mailing list before, but now you are
>hearing it from someone uninvolved in that process. A trivial script reports
>93866 lines of code in the reiser4 directory. That's a lot of code to
>navigate without a map.
>
>Having got that off my chest, here is one example of a plugin struct that
>could use documentation. There are several other examples -- notably the
>pseudo.c structure which is relatively uncomplicated and the directory plugin
>which is about as complicated as this example "file" plugin.
>
> [PSEUDO_FILE_PLUGIN_ID] = {
> .h = {
> .type_id = REISER4_FILE_PLUGIN_TYPE,
> .id = PSEUDO_FILE_PLUGIN_ID,
> .pops = &file_plugin_ops,
> .label = "pseudo",
> .desc = "pseudo file",
> .linkage = TYPE_SAFE_LIST_LINK_ZERO
> },
> .open = open_pseudo,
> .truncate = eperm,
> .write_sd_by_inode = eperm,
> .readpage = eperm,
> .capturepage = NULL,
> .capture = NULL,
> .read = read_pseudo,
> .write = write_pseudo,
> .release = release_pseudo,
> .ioctl = eperm,
> .mmap = eperm,
> .sync = sync_common,
> .get_block = eperm,
> .flow_by_inode = NULL,
> .key_by_inode = NULL,
> .set_plug_in_inode = set_plug_in_inode_common,
> .adjust_to_parent = NULL,
> .create = NULL,
> .delete = eperm,
> .add_link = NULL,
> .rem_link = NULL,
> .owns_item = NULL,
> .can_add_link = cannot,
> .can_rem_link = cannot,
> .setattr = inode_setattr,
> .getattr = getattr_common,
> .seek = seek_pseudo,
> .detach = detach_common,
> .bind = bind_common,
> .safelink = NULL,
> .estimate = {
> .create = NULL,
> .update = NULL,
> .unlink = NULL
> },
> .wire = {
> .write = wire_write_pseudo,
> .read = wire_read_pseudo,
> .get = wire_get_pseudo,
> .size = wire_size_pseudo,
> .done = wire_done_pseudo
> },
> .init_inode_data = NULL,
> .pre_delete = NULL,
> .cut_tree_worker = cut_tree_worker_common,
> .destroy_inode = NULL,
> },
>
>Thanks,
>-pvh
>
>
>
Zam, vs is releasing a patch today, so can you document this for us?
Thanks.
Hans
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Plugin structure documentation request
2005-12-14 9:09 ` Hans Reiser
@ 2005-12-14 11:06 ` Alexander Zarochentsev
0 siblings, 0 replies; 3+ messages in thread
From: Alexander Zarochentsev @ 2005-12-14 11:06 UTC (permalink / raw)
To: Hans Reiser; +Cc: Peter van Hardenberg, reiserfs-list
On Wednesday 14 December 2005 12:09, Hans Reiser wrote:
> Peter van Hardenberg wrote:
> >It would be quite excellent if we could have even a one sentence
> > description of all the plugin structures. This structure includes many
> > operations not found in conventional VFS, and many of the calls are not
> > described in any documentation I have found.
> >
> >I must confess I am feeling some frustration at the complete lack of
> >documentation of the project. I have very few complaints about the quality
> > of the code, but despite having spent four months working through file
> > after file I still regularly stumble across areas we have not had an
> > excuse to delve into and have no idea how they work in a general sense or
> > what they do. This kind of documentation does not take particularly long
> > to generate but would save new users of the code many, MANY long hours
> > spent poring over code and tracking function calls through the enormous
> > structure.
> >
> >I know you have heard it from the kernel mailing list before, but now you
> > are hearing it from someone uninvolved in that process. A trivial script
> > reports 93866 lines of code in the reiser4 directory. That's a lot of
> > code to navigate without a map.
> >
> >Having got that off my chest, here is one example of a plugin struct that
> >could use documentation. There are several other examples -- notably the
> >pseudo.c structure which is relatively uncomplicated and the directory
> > plugin which is about as complicated as this example "file" plugin.
> >
> > [PSEUDO_FILE_PLUGIN_ID] = {
> > .h = {
> > .type_id = REISER4_FILE_PLUGIN_TYPE,
> > .id = PSEUDO_FILE_PLUGIN_ID,
> > .pops = &file_plugin_ops,
> > .label = "pseudo",
> > .desc = "pseudo file",
> > .linkage = TYPE_SAFE_LIST_LINK_ZERO
> > },
> > .open = open_pseudo,
> > .truncate = eperm,
> > .write_sd_by_inode = eperm,
> > .readpage = eperm,
> > .capturepage = NULL,
> > .capture = NULL,
> > .read = read_pseudo,
> > .write = write_pseudo,
> > .release = release_pseudo,
> > .ioctl = eperm,
> > .mmap = eperm,
> > .sync = sync_common,
> > .get_block = eperm,
> > .flow_by_inode = NULL,
> > .key_by_inode = NULL,
> > .set_plug_in_inode = set_plug_in_inode_common,
> > .adjust_to_parent = NULL,
> > .create = NULL,
> > .delete = eperm,
> > .add_link = NULL,
> > .rem_link = NULL,
> > .owns_item = NULL,
> > .can_add_link = cannot,
> > .can_rem_link = cannot,
> > .setattr = inode_setattr,
> > .getattr = getattr_common,
> > .seek = seek_pseudo,
> > .detach = detach_common,
> > .bind = bind_common,
> > .safelink = NULL,
> > .estimate = {
> > .create = NULL,
> > .update = NULL,
> > .unlink = NULL
> > },
> > .wire = {
> > .write = wire_write_pseudo,
> > .read = wire_read_pseudo,
> > .get = wire_get_pseudo,
> > .size = wire_size_pseudo,
> > .done = wire_done_pseudo
> > },
> > .init_inode_data = NULL,
> > .pre_delete = NULL,
> > .cut_tree_worker = cut_tree_worker_common,
> > .destroy_inode = NULL,
> > },
> >
> >Thanks,
> >-pvh
>
> Zam, vs is releasing a patch today, so can you document this for us?
> Thanks.
>
> Hans
fs/reiser4/plugin/plugin.h:file_plugin structure has comments.
--
Alex.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-12-14 11:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-14 8:33 Plugin structure documentation request Peter van Hardenberg
2005-12-14 9:09 ` Hans Reiser
2005-12-14 11:06 ` Alexander Zarochentsev
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.