On Thu, Apr 16, 2009 at 10:41:33AM +0800, Wu Fengguang wrote:
quoted text
> On Wed, Apr 15, 2009 at 09:57:49PM +0800, Andi Kleen wrote:
> > > That's pretty good separations. I guess it would be convenient to make the
> > > extra kernel flags available under CONFIG_DEBUG_KERNEL?
> > 
> > Yes.
> > 
> > BTW an alternative would be just someone implementing a suitable
> > command/macro in crash(1) and tell the kernel hackers to run that on
> > /proc/kcore. That would have the advantage to not require code.
> 
> Hmm, that would be horrible to code/maintain. i

Actually the bits are enums and crash is able to read C type 
information.

quoted text
> One major purpose of
> /proc/kpageflags is to export the unstable kernel page flag bits as
> stable ones to user space. 

That's the first case ("administrator"), but not the second one
("kernel hacker")

BTW not saying that crash is the best solution for this, but
it's certainly an serious alternative for the kernel hacker
case. 

quoted text
> Note that the exact internal flag bits can
> not only change slowly with kernel versions, but more likely with
> different kconfig combinations.

Really? The numbers should be the same, at least for a given
architecture with 32bit/64bit.

quoted text
> Followed are their detailed locations. Did we found a bug? ;-)

I think all pages > 0 in a larger page are tails.  But I don't
claim to understand all the finer details of compound pages.

-Andi

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