Realistically, all you need to do to _not_ screw up binary module
compatibility to do this 'move' is:
1) make a vfs_generic_rename() function which is exported
by the kernel (for use in FS modules)
2) DO NOT change the inode_operations structure at all
3) Change the vfs rename() system call to check if the
inode_operations rename() function is NULL, and if so have it call
the vfs_generic_rename()
4) Remove the FS-specific rename functions from the filesystems
which can use the generic method.
The result of this is that the kernel interfaces do not change (adding
a new interface does not consitute a change in the interface), but you
get the added benefit that the filesystem itself can decide whether it
wants to use the generic code or implement rename itself.
I don't see this as being a major problem, assuming it is done
"right." I can only assume that you do not plan to remove the
rename() inode_operation.
If you do plan to actually _change_ the inode_operation, please wait
until 2.3.
-derek
Alexander Viro <viro@math.psu.edu> writes:
> On Sun, 7 Feb 1999, Khimenko Victor wrote:
>
> > "Easily" ? Are you joking ? With moves like planned move of rename() from
> > filesystem-level to VFS-level are forced to redesign all modules (AFS peoples
> > are heppy to hear about this move, I know :-))) ! So if module will be
> > saparated from main kernel this will become mantainance nightmare (like PCMCIA
> > just now).
>
> Victor, in case you've missed it: rename() change is being done *not* to
> screw modules up. Please, learn to read. BTW, do you realize that
> dependency of modules on VFS is half of problem? It's not official tarball
> vs all add-ons. It's core kernel and bunch of filesystems, some of them
> available in the official tarball. Even if we say 'f*ck 3rd party modules'
> we still have all officialy supported filesystems on hands to fix. Parts
> of VFS are scattered over all filesystems. It's a permanent pain in ass
> both for VFS and for filesystem drivers. Code duplication is evil.
> Excessively wide interfaces are evil. And we are paing for that.
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH
warlord@MIT.EDU PGP key available
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/