Re: make flock_lock_file_wait static

[Trond Myklebust]

ty den 11.01.2005 Klokka 09:31 (+0100) skreiv Arjan van de Ven:
> On Mon, 2005-01-10 at 09:23 -0500, Trond Myklebust wrote:
> > må den 10.01.2005 Klokka 09:38 (+0100) skreiv Arjan van de Ven:
> > >  
> > > > is "sooner or later" and "maybe someone else uses it" worth making
> > > > everyone elses kernel bigger by 500 bytes of code ?
> > > 
> > > eh 60 not 500; sorry need coffee
> > 
> > It's an API that provides *necessary* functionality for those
> > filesystems that wish to override the standard flock(). It was very
> > recently introduced by a third party, so we haven't had time to code up
> > an NFS flock yet.
> 
> where "recently" is last september....
> bloating the kernel unused since then...

Feel free to help out if you think the NFS development effort is
understaffed.

> If it is going to take a LOT longer though I still feel it's wrong to
> bloat *everyones* kernel with this stuff.
> 
> (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.


Concerning this case, though, and to make what I said in the earlier
mails (a lot) more explicit.

If you unexport flock_lock_file_wait(), then you might as well back out
the entire bloody ->flock() changeset instead because keeping the
->flock() VFS override support without the functionality to make
implementation practical (which is what you appear to want to do) is a
waste of more than 70 bytes of memory.

Now please go and figure out what it is you actually want to do here.

Trond
-- 
Trond Myklebust <trond.myklebust@xxxxxxxxxx>

-
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/