Messages in this thread | | | Date | Fri, 7 Jan 2005 10:00:14 +0100 | From | Ingo Molnar <> | Subject | Re: [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/
| |