* Andrew Morton <[email protected]> wrote:
> If we just want some pseudo-private fd space for glibc to use then I'd
> have thought that the existing code could be tweaked to do that:
> top-down allocation, start at some high offset, etc. But apparently
> there's more to it than this.
top-down has the problem of rlimits: 'where is top' is a variable
notion.
start-at-high-offset using the existing scheme has a 'bitmap size'
problem: even at 2^28 the bitmap size would be 32+ MB. per process (!).
The bitmap could be allocated on demand, but that slows down the current
code, uglifies it, and it would still end up somewhere looking a bit
like Davide's clean new code.
so, instead of trying to mesh this thing into the old fd data structures
which are very much centered around and tailored to the
continuous-allocation usage model, Davide cleanly separated it out into
a separate data structure that fits this independently-allocated usage
model well and leaves the original data structure alone. I'm strongly in
favor of such clean data structure separations.
Ingo
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
