On Mon, 4 Jun 2007, Andrew Morton wrote: > > must be RCU friendly (proper barriers) since it's used in > > lockless code, > > Haven't looked at that. > > > and must have flags associated to an allocation. > > Don't understand that.
It needs to be able to store flags (like close-on-exec, and maybe more) together with a file*. > > And I'm > > leaving out the O(1) part, that for something like this, is just silly not > > to have it. This is really an array. > > Having to walk down a tree in fget_light() would kinda suck. > > What about my b)? Right now, I'm working on a patch that uses fdmap even for legacy (sequential) fd allocations. With a cleaner interface, w/out having code all around the kernel that access fdtable members directly. This should cut some code WRT using two different allocators (code in fs/file.c will almost zip-away), and maybe it'll look even better and have some new comments too ;) It can be, in theory, completely abstracted and moved into lib/. I'll look into it once I completed the first cleanup, assuming the whole thing won't look worse than before :) - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
