From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
viro@zenII.uk.linux.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@osdl.org>
Subject: Re: make flock_lock_file_wait static
Date: Tue, 25 Jan 2005 10:58:12 -0800 [thread overview]
Message-ID: <20050125185812.GA1499@us.ibm.com> (raw)
In-Reply-To: <1105472182.3917.49.camel@laptopd505.fenrus.org>
On Tue, Jan 11, 2005 at 08:36:22PM +0100, Arjan van de Ven wrote:
> On Tue, 2005-01-11 at 14:16 -0500, Trond Myklebust wrote:
> > > (you may think "it's only 100 bytes", well, there are 700+ other such
> > > functions, total that makes over at least 70Kb of unswappable, wasted
> > > memory if not more.)
> >
> > A list of these 700+ unused exported APIs would be very useful so that
> > we can deprecate and/or get rid of them.
>
> http://people.redhat.com/arjanv/unused
>
> has the list of symbols that are unused on an i386 allmodconfig based on
> the -bk tree 2 days ago.
<donning asbestos suit with the tungsten pinstripes...>
SAN Filesystem is an out-of-tree GPL module that uses the following:
o blk_get_queue(): used to submit I/O requests using the
make_request_fn().
o sock_setsockopt(): used to control communication with other
nodes in the SAN Filesystem.
o vfs_follow_link(): used to interpret symbolic links, which
might point outside of SAN Filesystem.
SDD is a binary module that has committed to get itself to GPL on its
first release after December 31, 2005. It uses:
o __read_lock_failed() and __write_lock_failed(): due to SDD's use
of read_lock() and write_lock(). So, if the plan is to change
read_lock() and write_lock() to do something different, never mind!
So, could the exports for the following symbols from the list please be
retained through December 31, 2005?
blk_get_queue
sock_setsockopt
vfs_follow_link
__read_lock_failed
__write_lock_failed
Thanx, Paul
PS. Yes, there are more than two out-of-tree modules in IBM. Some were
not affected by this list. One is looking carefully at Al Viro's
propagation-node design to see if it does what they need (looks
promising thus far). Still others are having more trouble accepting
the need to stop being binary modules in the near future, but that
is their problem, not yours! ;-) To be fair, at least one in the
last group has some legitimate IP issues, which we are working on.
next prev parent reply other threads:[~2005-01-25 19:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-09 19:42 make flock_lock_file_wait static Arjan van de Ven
2005-01-09 22:44 ` Trond Myklebust
2005-01-10 8:19 ` Arjan van de Ven
2005-01-10 8:38 ` Arjan van de Ven
2005-01-10 14:23 ` Trond Myklebust
2005-01-11 8:31 ` Arjan van de Ven
2005-01-11 19:16 ` Trond Myklebust
2005-01-11 19:36 ` Arjan van de Ven
2005-01-25 18:58 ` Paul E. McKenney [this message]
2005-01-26 3:10 ` Andrew Morton
2005-01-26 9:01 ` Arjan van de Ven
2005-01-26 16:07 ` Paul E. McKenney
2005-01-26 18:59 ` Arjan van de Ven
2005-01-28 14:14 ` Paul E. McKenney
2005-01-28 18:50 ` Christoph Hellwig
2005-01-28 19:01 ` Arjan van de Ven
2005-01-26 9:43 ` Christoph Hellwig
2005-01-26 9:51 ` Al Viro
2005-01-26 9:55 ` Christoph Hellwig
2005-01-26 10:00 ` Al Viro
2005-01-15 21:35 ` Adrian Bunk
2005-01-15 22:07 ` Trond Myklebust
2005-01-10 8:35 ` Ken Preslan
2005-01-10 8:44 ` Arjan van de Ven
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=20050125185812.GA1499@us.ibm.com \
--to=paulmck@us.ibm.com \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
--cc=viro@zenII.uk.linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).