Re: make flock_lock_file_wait static

[Paul E. McKenney]

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