All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Kacur <jkacur@rogers.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Greg Stark <gsstark@mit.edu>, Jean Delvare <khali@linux-fr.org>,
	bunk@stusta.de
Subject: Re: 2.6.11 breaks modules gratuitously
Date: Fri, 18 Mar 2005 14:01:02 -0500	[thread overview]
Message-ID: <1111172461.5993.10.camel@linux.site> (raw)
In-Reply-To: <20050318194915.580c3511.khali@linux-fr.org>

On Fri, 2005-03-18 at 13:49, Jean Delvare wrote:
> 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,

So perhaps we can introduce a new term to linux kernel development,
reexporting a symbol can now be known as debunking?

(sorry, sorry, I couldn't resist)


  reply	other threads:[~2005-03-18 19:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3JrTO-1C4-41@gated-at.bofh.it>
2005-03-18 18:49 ` 2.6.11 breaks modules gratuitously Jean Delvare
2005-03-18 19:01   ` John Kacur [this message]
2005-03-18 19:14     ` Adrian Bunk
2005-03-18 15:33 Greg Stark
2005-03-18 16:00 ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1111172461.5993.10.camel@linux.site \
    --to=jkacur@rogers.com \
    --cc=bunk@stusta.de \
    --cc=gsstark@mit.edu \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.