技术blog搬家完成

今天把程序完善了一下,然后重新运行。在碰见blogger的发布限制之前,我先遇到了程序Bug……今天往程序里面加了转移评论的功能,这个bug就是出在这个地方。有的blog是草稿,然后程序访问的时候,返回的是访问被拒绝。程序在这个页面里面找评论,于是挂了……改了之后,重新运行,碰见了blogger的发布限制……原打算明天再说,但是Roy的话给了我启发。虽然单个blog有限制,但是能够开多个blog,然后把那些blog导出,再导入技术blog。这样就解决了问题,使得整个搬家工作能够在一天内做完。现在看起来,Blogger的限制大约是每天50贴,还算合理。但是那些搬家程序不知道是怎么混的~另外,总结经验,以后要先尝试运行一遍,再将改动予以实行……

技术blog搬家

其实我有一个技术blog,但是没什么人去……原来架在mblogger.cn上,但是这个地方越来越缺乏管理,用户流失严重,就是懒得搬。话说这个也是我一开始写的blog。这个地方基于.Text平台,提供metaWeblog接口。我打算搬到blogger。在网上找了一下,有现成的博客搬家的地方。但是试了一下,都不能用……比如说,http://blogmover.redv.com/,这个地方能够读出原来的blog,但是写到blogger的模块出问题了……又如maikr,需要登录才能用,而网站挂了,于是注册不了……最后只好自己写一个搬家程序了……既然近期学习python,那么练一下也好。python自带xmlrpclib模块,能够和metaWeblog通讯。尝试了一下,metaWeblog的接口还真好用,不一会儿就能够读出blog了。话说python生产力就是高阿,随便弄一下就好了,有什么问题搜一下也能很快解决。如果…… 如果python不是用空格/缩进表示层次的话,那就更好了!然后去研究写到blogger的方法。这时候我发现,虽然metaWeblog基于blogger API,但是那是老的blogger API……新的Blogger被Google整合到了GData API框架里面,于是巨麻烦无比……Google的人们是不是太聪明了…… 总是觉得自己发明的东西比较好,不用现成的…… 然后弄出麻烦的东西,光了解就要不少时间……还好有python的gdata库,自带了访问blogger服务的样例。但是又有一个问题:貌似Blogger的GData访问方法被GFW掉了……只好改了,用SSL,又耗掉一堆时间……最后,折腾了一大堆,终于是把这个搬家程序写出来了……但是,最后用的时候碰见问题了: status 400Blog has exceeded rate limit or otherwise requires word verificationfor new posts COW! 这可怎么搬家啊……

关于A20地址线的那些事情

从前在BIOS里面见过关于A20地址线的选项,后来启动FreeDOS什么的时候好像也见过A20的事情,一直不知道是干嘛的……后来某天看BSD loader代码的时候,看见启用A20地址线的事情…… 于是去wiki上查了一下,原来是这么回事……8086那个时候,地址线只有20位,叫做A0~A19,也就是没有A20地址线的。2^20=1M,因此那时能够访问的内存范围是1M。那个时候也分段,地址由段寄存器左移4位,加上基地址,得到物理地址。段寄存器和基地址都是16位的,这样就能够访问20位的空间了。但是有个问题……段寄存器最大FFFF,基地址也是。所以地址最大是FFFF:FFFF,但是FFFF左移四位得到FFFF0,加上FFFF,得到10FFEF,也就是FFFFF+FFF0。但是物理内存只有1M,最大物理地址范围应该是0~FFFFF,因此多了FFF0,超出了物理地址范围。这样,访问到超出范围的时候,8086会自动做一个处理,把高位的1删掉,也就是10xxxx->xxxx,然后返回对应位置。 按理来说,这是个bug,8086应该返回个错误啥的。但是,既然这已经是事实了,有的程序就开始用这一点,来访问0~FFEF的内存范围,差不多是前64K少一些的范围。这就为日后的新CPU出了难题…… 80286,80386等等更NX的处理器出现了,他们支持访问更大的内存范围。自然,10xxxx和xxxx也就指向了不同的地方。但是,跑那些用到从前bug的老程序的时候,就出问题了…… 改了10xxxx的xxxx不变,导致乱七八糟的问题……IBM他们就脑残了一下,说,我们在A20地址线(也就是那个1的位置……)装个开关吧~ 然后又脑残一下,看见键盘控制器正好有一根线空着,就说,我们让键盘控制器来管这个开关吧~于是,著名的Gate A20就这么产生了……打开:输出0xd1到0x64端口,等8042(键盘控制器)空了,再输出0xdf到0x60端口 保护模式的操作系统,自然都需要访问1M以上的内存,而且不希望某一位地址一直是0。所以保护模式的操作系统启动步骤之一,就是打开A20。但是,IBM那些人们没想到,日后有些环境需要频繁切换A20端口,而键盘控制器是如此之慢…… 他们当初认为,这个切换发生频率很低,因此慢一点没关系…… 于是就有了Fast Gate A20的事情。利用0x92端口,读入之后,把第二位改成1,然后写回去,能快一点。但这个引起了新的bug。毕竟只有某些系统支持0x92端口的这个用发,而有些系统…… 改了0x92会导致没有显示之类的,所以有危险……后来么,intel也不爽了,就搞了个0xee端口,读打开A20,写关闭…… 速度比从前更快了…… 于是,这样就有了3中方法,由慢到快。某些程序就一个一个试,试了一个验证一下。但是,缓存又来捣乱。有的系统虽然开了A20,还是会把几个字节缓存起来,10xxxx和xxxx一样…… 总的来说,A20就是个麻烦的事情,当初搞个BIOS调用之类的也就over了么…… 不过现在的新的系统,基本上都没有A20的问题了,虽然打开A20还是系统启动的必要步骤之一……参见A20 – a pain from the past

80×86 保护模式 内存访问 学习总结

话说这个80286搞出来的保护模式,又是分段又是分页,从前没好好研究过,从来就没有搞清楚过……家里翻到一本老教材,《微型计算机技术及应用——从16位到32位》,里面讲80386的章节,终于基本上讲清楚了……假设现在是即分段又分页的情况…… 首先,程序里面引用一个地址,其实指的都是逻辑地址。这样的引用需要两部分数据:段选择子以及段内偏移量。然后么,段选择子基本上就放在老的段寄存器里面,不过现在是起一个索引的作用。段选择子其实分几部分。总共16位,前13位是个索引,接下来1位指定是到LDT还是GDT里面找。最后两位是特权级。LDT和GDT,一个是局部描述符表,一个是全局描述符表,反正是两张表,存了一大堆的段描述符。表的位置放在LDTR和GDTR两个寄存器里面。现在研究内存访问,所以只讨论存储段描述符,每个8个字节,包括了段的开始地址(32位)、界限(20位),还有一堆标志什么的。用前面那个索引,从LDT或GDT里面找到描述符,然后就有了段基地址。之前需要检查偏移量符合界限,以及其他各种权限之类的检查。最后加上偏移量,我们就得到了线性地址~ 分段部分完成~ 然后,线性地址有32位。把它分为3段:10位,10位,12位。系统有一堆控制寄存器,其中,CR3里面,保存着页目录的基地址。页目录也是一个表,每项4个字节,每个里面都有一个页表基地址…… 当然还有一堆别的东西,什么权限、标志之类的……线性地址的第一段,10位,就是这个表的索引。把它乘以4(每项4个字节么……),加上CR3里面的基地址,就有了页表的基地址……页表的结构也差不多,也是4个字节一项。用线性地址第二段,10位,乘以4,加上页表基地址,就有了页基地址……最后,拿第三段,12位,加上业基地址,终于…… 我们得到了物理地址! 接下来么,做一些数学计算。页内偏移量(线性地址第三段)有12位,2^12=4*1k=4k,和一页大小为4k吻合~线性地址前两段,每段10位,对应的表可以有1k项。所以,经过这两级,可以索引1M个页。每个页4k那么大,所以…… 总共4G。其实这个计算很NC对吧…… 总共32位,没有1位浪费,全都用来索引的情况下,当然可以索引2^32=4G……然后,一个页表有多大呢?一项4字节,共1024字节,所以一个页表4k大。总共1k个页表,所以页表总共占4M那么多地方。页目录表么,就4k大啦,比起页表也不算什么……然后,段的界限只有20位,2^20=1M,难道一个段只有1M那么大?其实剩下的标志里面有一个粒度位G,能够指定界限以1字节还是4k为单位。以4k为单位的时候,就能有1M*4k=4G那么大的段,这个就很完美了么~段选择子有16位,因此最多有2^16=65536个段,真多…… 然后,这样n级转换不是很慢么,所以系统里还有转换缓冲区。貌似这个区操作系统还可以控制,让哪些转换结果留在缓冲里面,这样下次碰见一个逻辑地址就不用多级转换了……另外,程序用到段选择子的时候,必然都在6个段寄存器里。所以,每次把东西扔到段寄存器里面去,CPU就把对应的段描述符装到一个隐藏的寄存器里面,这样,大部分时间就不用去查LDT/GDT之类的了……