On Mon, Oct 15, 2007 at 05:49:10PM -0700, Dave Hansen wrote: > On Mon, 2007-10-15 at 19:35 -0500, Matt Mackall wrote: > > Perhaps we need something like: > > > > flags = page->flags; > > userflags = > > FLAG_BIT(USER_REFERENCED, flags & PG_referenced) | > > ... > > > > etc. for the flags we want to export. This will let us change to > > > > FLAG_BIT(USER_SLAB, PageSlab(page)) | > > > > if we make a virtual slab bit. > > Yeah, that looks like a pretty sane scheme. Do we want to be any more > abstract about it? Perhaps instead of USER_SLAB, it should be > USER_KERNEL_INTERNAL, or USER_KERNEL_USE. The slab itself is going away > as we speak. :)
Perhaps. SLUB is still "a slab-based allocator". SLOB isn't, but I intend to start making it use PG_slab shortly anyway. > > And it shows up in grep. > > > > Unfortunately, i386 test_bit is an asm inline and not a macro so we > > can't hope for the compiler to fold up a bunch of identity bit > > mappings for us. > > We could also Yeah, that looks like a pretty sane scheme. Do we want to > be any more abstract about it? Perhaps instead of USER_SLAB, it should > be USER_KERNEL_INTERNAL, or USER_KERNEL_USE. The slab itself is going > away as we speak. > > For the bits that we want to export, we could also add the unoptimized > access functions for any that don't already have them: > > #define __ClearPageReserved(page) __clear_bit(PG_reserved, > &(page)->flags) Confused. Why are we interested in clear? -- Mathematics is the supreme nostalgia of our time. - 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/
