> > With the registration API modules doing HSM/LSM/... can
> just register
> > handlers
> > without having to modify the file system code. Otherwise we
> would have to
> > hand code additional hooks for independently loadable modules.
>
> a) if the HSM/whatever is so standalone that it should patch ext2 code
> it is truely generic and thus above the filesystem.
> b) you don;t even export the register/unregister to modules,
> not mention
> other ext2/ext3 core functionality that it would need.
> c) looks at the 'would' there is no such code currently and
> if it gets
> a real consern it still could be added. Don't bloat the kernel
> more than you really need to..
Actually we are currently developing HSM application that stacks on top of
standard file system (ext3 and XFS today) and we are using EA to store HSM
specific information with each inode. However, we are not using registration
API, but rather store this in user EA (even if we don't like some
limitations of user EA), because registration API is not exported and
registration API is per-FS and not generic. This would mean that we would
need to have handlers defined for each supported filesystem (ext3 and XFS
today, reiserfs and JFS in near future). As we use user EA, we just call VFS
EA operations of the bottom FS (ext3 or XFS or any other FS that supports
EA).
I agree with your point that this interfaces needs to be exported, but I
would also prefer if they would be generic in terms of being able to
register the same EA handler for each FS supporting EAs (an allowing
extensions/registrations).
I think that we could also then have only single ACL code for both ext2 and
ext3 - currently ACL patch adds similar (same?) code to both ext2 and ext3
and this code could be shared for sure.
Regards,
Luka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:30 EST