lkml.org 
[lkml]   [1999]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: proper place to discuss kernel 'bloatedness'?
From
Date
[ 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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.074 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site