Date: Fri, 18 Mar 2005 19:49:15 +0100
From: Jean Delvare <khali@linux-fr.org>
To: Greg Stark <gsstark@mit.edu>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.11 breaks modules gratuitously
Message-Id: <20050318194915.580c3511.khali@linux-fr.org>
In-Reply-To: <3JrTO-1C4-41@gated-at.bofh.it>
References: <3JrTO-1C4-41@gated-at.bofh.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1689
Lines: 34

Hi Greg,

> When you guys go on these "make needlessly global code static" kicks
> you should maybe consider that even functions that aren't currently
> used by any other area of the tree might be useful for module writers.
> 
> Instead of just checking which functions are currently used by other
> parts of the kernel perhaps you should think about what makes a
> logical API and stick to that, even if not all of the functions are
> currently used.

I'd second that. Cleanups are good and I do not deny that Adrian Bunk
has been doing a terrific work. However, unexporting or removing
functions just because they have no current user in the kernel tree is
not always a clever thing to do. Keeping things square and logical
should be taken into consideration, as should the possibility that some
function might be used outside of the kernel tree. I do *not* mean
entire interfaces only used outside of the kernel tree, because these
are highly questionable, but functions that are part of a larger set of
functions representing an interface, most of which are used inside the
kernel. In this specific case, dropping exports or removing functions
make very little sense to me and is sometimes calling for trouble, as
Greg just underlined. In some cases, the functions are likely to be
reintroduced/reexported a few months later and we certainly could use
our time in a more useful way than undoing and redoing things.

Thanks,
-- 
Jean Delvare
-
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/