Re: proper place to discuss kernel 'bloatedness'?

Alexander Viro (viro@math.psu.edu)
Sun, 7 Feb 1999 16:35:50 -0500 (EST)


On Mon, 8 Feb 1999, Khimenko Victor wrote:

> In <Pine.SOL.3.95.990207144051.11583A-100000@weyl.math.psu.edu> Alexander Viro (viro@math.psu.edu) wrote:
> > BTW, do you realize that dependency of modules on VFS is half of problem?
>
> Uh ? How you could make filesystem modules without dependency on VFS ???
Without dependency on details of VFS internals.

> > It's core kernel and bunch of filesystems, some of them available in the
> > official tarball.
>
> Correct.
>
> > Even if we say 'f*ck 3rd party modules' we still have all officialy supported
> > filesystems on hands to fix.
>
> Yes. And when next tarball will be made most of them will be fixed already.
> At least important ones. With add-ons it's always catch-up :-((

Gee... How nice. Maybe your know a spell that would magically fix NFS in
this round of changes? That's what I'm fighting with right now. And
[U]MSDOS, for that matter (less terrible). Most of them will be fixed
already... Sheesh... Sure they wiil. Do you realize that things that are
PITA in 3rd-party modules are PITA in the official ones? No? Yes, they
will be fixed. Just that 3rd-party stuff is pain in the asses of its
maintainers while the stuff in official kernel is pain in my ass right
now. Code is code and breakage is breakage, no matter where the breakage
happens.

> > 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.
>
> Interfaces changes sometimes. In case of Linux kernel interfaces changes
> more often then anywhere alse (hm... may be interfaces in GNOME are changes
> even faster sometimes :-) since binary compatibility are not goal of prime
> developers (Linus and Alan at least :-)... With tarball it's not so big
> problem: you always can recompile modules when switching to new kernels...

Yeah??? In case you've missed it: d_move() call goes out of foo_rename()s
and moves to vfs_rename(). And it's not idempotent[1]. If that wouldn't
happen there would be no need even to recompile modules. Problem with
those advocates - they can vgrep but they can't read. Sheesh...

-
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/