>From: Aurelien Degremont - Stagiaire <degremont@xxxxxxxxxxx>
>Dean Roehrich a écrit:
>> If your filesystem of choice doesn't have an fsid, then you could just
>> generate one that is valid while the filesystem is mounted and is not writte
>> to the filesystem, or you could come up with something else. Whatever you
>> choose for an fsid should fit into a 64-bit type.
>> 1) The fsid should be a parameter to dm_send_mount_event() and
>> dm_send_namesp_event() and dm_send_unmount_event().
>> The get_fsid op in struct filesystem_dmapi_operations should be
>Ok, so we need to modify :
Well, more than that. I have some changes for this that I'll send in another
email, if you're willing to look over this.
>> 2) The dm_fsys_vector_t should be folded into struct
>> filesystem_dmapi_operations. The new ops vector should be
>> a parameter to dm_send_mount_event().
>> The part where today we copy the ops vector from
>> fsys_function_vector_t to dm_fsys_vector_t seems cumbersome and
>> just makes things hard to understand, so maybe
>> that copy should be skipped and some of these datatypes could
>> be removed.
>> The get_fsys_vector op in struct filesystem_dmapi_operations should be
>Move the fsys_vector pointer to dmapiops.
>Add a bitmask that informs which functions id set when registering.
>Change all the dm_sys_vector calls in dmapi.
>Maybe the dm_vector_map should be replace by a list_head ?
I'm sure now that we can throw away dmapi_register() and dmapi_unregister(),
and we can send &filesystem_dmapi_operations as a parameter in the mount
event. This assumes the fsid changes have been finished.
Looking at filesystem_dmapi_operations in its current form, all of those
vectors are valid only after dm_send_mount_event() has been called. We will
have to change a few things with respect to ->inode_to_fh; this is used only
by dm_ip_to_handle(), but all callers of dm_ip_to_handle() followup with a
call to dm_find_fsreg_and_lock(). We have enough info in the fsreg so that we
could search the dm_registers list by sb. So, all callers of
dm_ip_to_handle() would be changed to call a new
dm_find_fsreg_by_sb_and_lock() first and then dm_ip_to_handle() second.
>> 3) It would be nice to keep in mind distributed filesystems and stackable
>> filesystems; try to make it easier, not harder, to move in those
>> directions. Unfortunately, I have no experience with the Linux
>> view of stackable filesystems and I don't quite know how to approach
>> that problem.
>Ok, I'm not specialist neither. I'll try...
I think we're almost there.