Search This Blog

Sunday, June 17, 2007

a gtk+'s bug fixed

the bug wat not fixed until gtk+-2.10.13
with previous gtk+ versions,a save dialog will stretch out and draw back very frequently,as a result,the cpu load will be 100%
now all gtk+ applications get right.

Friday, June 15, 2007

a bug of x60

if the modem is disabled in bios,then the sound card will be disabled,too.
after I disabled the modem,I must run "alsaconf" to drive the sound card every rebooting.

Tuesday, June 12, 2007

paging in linux

ever since 2.6.11,there is a new level named pud(page upper directory) plusing to pgd,pmd,pte,and so something chaged.
what confused me is that,as ULK said:
"For 32-bit architectures with no Physical Address Extension, two paging levels are sufficient. Linux essentially eliminates the Page Upper
Directory and the Page Middle Directory fields by saying that they contain zero bits. However, the positions of the Page Upper Directory
and the Page Middle Directory in the sequence of pointers are kept so that the same code can work on 32-bit and 64-bit architectures. The
kernel keeps a position for the Page Upper Directory and the Page Middle Directory by setting the number of entries in them to 1 and
mapping these two entries into the proper entry of the Page Global Directory."
so I wonder how does the kernel eliminate pud and pmd as well as keep the position of them to make the code work on 32-bit and 64-bit arch?

at first,I thought pgd still leads the paging unit to pud,then pud to pmd,blablabla...
but it is completely wrong,coz the paging unit in x86 knows only 2-level paging when with pae disabled!
so in the hardware paging unit(x86)'s perspective,there are only pgd,pte,nothing else.

but how to understand "the same code can work on 32-bit and 64-bit architechtures"?
well,I think it means the kernel folds pud and pmd away,so any functions or macros operating on pud or pmd will be lead to pgd,thus the code need no change between 32-bit and 64-bit.

anyone any ideas?plz show me:)