Messages in this thread | | | Date | Wed, 11 Feb 2004 17:20:46 -0800 | From | Andrew Morton <> | Subject | Re: PATCH - raise max_anon limit |
| |
Tim Hockin <thockin@sun.com> wrote: > > On Wed, Feb 11, 2004 at 04:42:33PM -0800, Andrew Morton wrote: > On Wed, Feb 11, 2004 at 04:42:33PM -0800, Andrew Morton wrote: > > > Indeed. MKDEV() already masks off the high order stuff, so that is OK. > >_ > > That means that we've lost the original idr key and can no longer remove > > the thing, doesn't it? > > No, it doesn't store the counter with the id. They expect you to do that. > My best understanding is that thi sis to prevent re-use of the same key. > I'm not sure I grok why it is useful. If you release a key, it should be > safe to reuse. Period. I assume there was some use case that brought about > this "feature" but if so, I don't know what it is. The big comment about it > is just confusing me.
Maybe Jim can tell us why it's there. Certainly, the idr interface would be more useful if it just returned id's which start from zero.
> > > On idr_get_new(), we can just check for > > > dev & ((1<<MINORBITS)-1) == (1<<MINORBITS)-1) > > > and return -EMFILE. > > >_ > > > That combined with a gfp mask to idr and the assumption that idr's > > > counter > > > won't ever grow beyond (sizeof(int)*8 - MINORBITS) (12) bits > > >_ > > > Shall I whip that up and test it? Do you prefer a gfp mask to idr_init > > > that > > > sticks around for all allocations or a GFP mask to idr_pre_get? > > Offer repeated. :)
Please. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |