>
>
> 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.
>
I'm not so sure if this is possible effectively. May be yes, may be no.
> > > 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.
>
No. There is difference. Not from mantainer side of course but from
end-user side. Looks like you could not understood that not all peoples
are kernel developers out there :-)) From mantainer of NFS and AFS this
breakage is the same PITA, but from end-user point of view there are big
difference: if it's included in tarball then chances are high that with
new releases changes will be done before new release will be put for
download (if this will break ext2fs, for example, then Linus will not
accept patch in first place ;-) and from END USER point of view this
breakage will not be noticeable at all. If something is not included in
tarball then user should wait for mantainer to catch up.
> > > 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...
>
I'm not used neither vgrep nor some other grep. Looks like you really do
not want understood that there are exist some peoples except of kernel
developers. For THEM it's big difference if something is included in
tarball or not...
-
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/