lkml.org 
[lkml]   [2005]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fs: Restore files_lock and set_fs_root exports

* Christoph Hellwig <hch@infradead.org> wrote:

> > What's under discussion here is "how to do it". Do we just remove things
> > when we notice them, or do we give (say) 12 months notice?
>
> Remove when we notice with a short (measured in weeks) period where
> that removal happens only in -mm. It's a price people have to pay for
> not submitting their code upstream.

let me chime in as the author/maintainer of Tux, which is an out-of-tree
patch that relies on VFS internals. VFS changes constantly break Tux in
one way or another, but i've not complained once because:

_I simply have no right to complain_

either i submit the code and then i can expect it to be taken into
account, or i dont. It's _the_ basic quid pro quo that keeps technology
moving towards mainline Linux. So if i have to fix up Tux (both for
exports and for other internal details), then that's the price. Often i
have to change Tux to do things differently - and in most cases it's Tux
that was doing things incorrectly. And note that Tux is not a
binary-only module, it's a fully GPL patch.

does this cause more work for me? Sure. Would i prefer to have less
work? Yes, but not in such a shortsighted way. Tux staying external is a
choice i made and i also care about Linux and i very much like the way
the VFS is evolving.

so my strong position is that even asking for any 'warning period' for
changes in VFS internals (including exports/unexports) would be
extremely rude. It would be rude not only towards the authors and
maintainers of mainline VFS code, but also towards other external
trees/drivers who do _not_ ask for any special status and accept the
deal: "follow internals, notice kernel people if they do bad stuff
(extremely rare in my case) and fix/redesign stuff if the external tree
is broken (much more common)".

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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