Messages in this thread | | | Subject | Re: proper place to discuss kernel 'bloatedness'? | From | Derek Atkins <> | Date | 08 Feb 1999 10:45:08 -0500 |
| |
[ Note: I have not been following this thread, so I've only seen the last, oh, 6 messages. I'm sorry if I'm replying out of context. -derek ]
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/
| |