*snip*
>there is andrea's patches
*snip*
>or will some or all of these always remain separate
>if so, why (did i saythat)?
>i've been on this list for a long time and i've never heard a statement one way or
>the other
Just to clarify the thing: arca-tree is the kernel I run/experiment with
and it' s far from be the official one (even if something could eventually
work better and being bugfree). I am simply making it public to allow
everybody to play with it (but if it' s not welcome and it' s causing a
lot of confusion I can return to a closed state ;). I am doing crazy
things in it ;). Today I moved check_pgt_cache() from the idle task to
do_try_to_free_pages() ;):
case 3:
if (check_pgt_cache())
return 1;
state = 0;
shrink_dcache_memory(i, gfp_mask);
the reason is that I never want that the idle task runs while I want that
check_pgt_cache() frees some useful page when we are low on memory. Is
this a good change? Maybe. But before ask on the list I _try_ to play
with things a bit and __try__ to understand things myself. This is why
sometimes there' s something of not documented on the list that is present
in arca-tree.
For example these days I am contributing in the developing of parport
IEEE1284 and so in latest arca-62 you can found the latest ieee1284 code
from Tim + some my fix. But the ieee1284 is far from be merged right
now (even if lp works fine and stable with it).
When there' s something I think that is good for merging I always try to
forward it to the proper place separately. Feel free everybody to merge my
code without tell me though (as far as the merging won' t break GPL of
course ;).
There are also some things that I don' t agree with the stock or ac11
kernel, like kswapd implementation that stop after exactly a jiffy, in
such case my tree really forks intentionally... but that are not critical
issues...
Hope this helps. Tell me if my tree is hurting btw.
Andrea Arcangeli
PS. There' s also the patch-IKD floating around (that you forget to
mention), and that is a separate patch that will remains separate
and that gives good instrument to do kernel debugging. I am
maintainting it myself too (Michael L. Galbraith maintains the
memleak part).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/