今天分布式实验报告的成绩出来了，结果很是差异呀，居然第三次实验报告交错了，虽然找老师求情还是不好用了，成绩已经没法改了，如果当初学软件质量保证的时候能够学以致用，按照Plan-Do-Check-Action的过程，提交完报告后再down下来check以下也不会发生这种问题了，教训啊！

    最近新装了Fedora14，感觉还不错，就是用惯了ubuntu对于Fedora的一些习性有些不太习惯，不如说第一次用sudo的时候系统提示当前用户不在sudoers列表中，只好再手动添加一遍了：

# Change to root
su
# Make /etc/sudoers writable
chmod +w /etc/sudoers
# Add user to sudoers
echo "username ALL=(ALL) ALL" >> /etc/sudoers
chmod -w /etc/sudoers
# Ctrl-D to resume

除了这个和ubuntu的用法不太一样，还有网卡的配置文件，添加软件源……，这些还好都能在网上找到相关的用法。但是当我在Fedora上安装samba共享linux下的目录时又出现了一个问题。按照网上的安装教程sudo yum install -y samba，然后设置/etc/samba/smb.conf文件，修改后testparm结果如下：

[global]
	server string = %h server(Samba,fedora)
	username map = /etc/samba/smbusers
	log file = /var/log/samba/log.%m
	max log size = 50
	cups options = raw

[printers]
	comment = All Printers
	path = /var/spool/samba
	printable = Yes
	browseable = No

[ShareFedora]
	comment = share with widows
	path = /home/water/Share
	valid users = water
	read only = No
	create mask = 0777
	directory mask = 0777
	guest ok = Yes
	locking = No

然后添加smb用户sudo smbpasswd -a username，在/etc/samba/smbusers加上，water = "network username"，然后重启samba服务，sudo service smb restart，在windows下访问测试说没有权限访问此计算机，在ubuntu下也用过samba和windows系统共享文件怎么就没出现过这种问题呢？于是又在网上查了其他的一些教程，才发现Fedora的防火墙selinux对samba进行了限制，需要修改防火墙过滤规则(/etc/sysconfig/iptables要求有root权限)，让防火墙不要拦截windows用户对samba的访问，sudo system-config-firewall，在打开的Trusted Services配置页面，选中Linux Samba和Samba Client，并Apply，然后重启samba服务，一切都正常访问了，另外还可以直接把防火墙关掉，虽然这样会引起安全问题。

    这个问题是我联想起前几天使用nc传文件的问题，我能给别人传cat filename | nc <ip> <port>，但是别人传过来的文件我却接受不到，nc -l 1234 > <filename>，今天试着把防火墙关了再试试，结果真的是Fedora的防火墙限制了一些网络程序的访问。

To Feel


 

What we all need and want. It's that simple. We want to be recognized by the people who matter to us, and they want the same.
This is especially true in love. Few things are as destructive as apathy. With feeling there is connection and with connection anything is possible.

 

首先下载工具链bcc+simulator+grmon，下载地址为http://www.gaisler.com/,我下的版本为sparc-elf-4.4.2-1.0.36b，tsim-eval-2.0.18，grmon-eval-1.1.44，分别为leon3的编译器、仿真器和debug工具，把他们解压到/opt/leon3/目录下，然后为了方便我把他们在/opt/leon3/bin下一次建立了软链接，为此写了一个简单的脚本，内容如下：

#!/bin/sh 
# Estiblish softlink for all the file in DIR 
DIR=$1 
objdir=/opt/or1200/tools/bin/ 
files=`dir $DIR` 
echo $files 
for file in $files 
	do 
		ln -s "$DIR"/"$file" ./"$file"		 
	done 
exit 0

之后把/opt/leon3/bin目录添加到PATH环境变量下，echo “PATH=$PATH:/opt/leon3/bin”>> ~/.bashrc，source ~/.bashrc，测试一下在终端中输入sparc-elf-gcc –version

得到如上结果，说明配置成功。

    然后就可以下载并编译ecos了，同样在leon的网站上下载了ecos-rep-1.0.9，这个是打过leon补丁的ecos，所以就拿来直接用了，下载后解压到~/workspace/leon3/下，配置和编译的过程功能可以参考gaisler网站上的指导，http://www.gaisler.com/cms/index.php?option=com_content&task=view&id=149&Itemid=224，

按照上面的说明，我下了ecos图形配置工具,ecostools-1.0，解压到/opt/leon3下，用同样的方法建立软链接，export ECOS_REPOSITORY, ecosconfig new sparc_leon3，一切都进行的很顺利，但是当运行configtool ecos.ecc时，意外悲剧发生了，

error while loading shared libraries: libwx_gtk-2.4.so: cannot open shared object file: No such file or directory，分析一下是缺少动态链接库，google了一下，在网上下了个rpm包，心想这下该好用了吧，不过程序又接连提示了缺少另外几个动态链接库，我急了，怎么会缺少这么多呢，于是就ldd了一下，

    linux-gate.so.1 =>  (0x005f3000)

    libtcl.so => /usr/lib/libtcl.so (0x00cfa000)

    libwx_gtk-2.4.so => not found

    libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00110000)

    libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00c26000)

    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00373000)

    libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x001ca000)

    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x001e3000)

    libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00548000)

    /lib/ld-linux.so.2 (0x00cbb000)

开始只是缺少libwx_gtk-2.4,可是后面又缺少libglib1.2等低版本的链接库，只好一个一个都给找到了，最后什么都不缺了，又提示段错误，无奈之下只好看一下有没有更高版本的crosstool，这个版本是在是太低了，很多已经废弃的链接库在我的ubuntu下都没有，果然找到了2010-03-05的版本的，下载地址见http://www.ecoscentric.com/devzone/configtool.shtml，

解压之后果然好用，虽然运行时还是会在终端下出现warning，但是已经能看到配置界面了

为了安装动态链接库，我把系统差点搞蹦了，原因就是我把缺少的.so文件直接复制到/usr/lib下了，这样系统就乱了，分不清连接低版本的还是高版本的了，网上的说法是把兼容库单独放到一个路径下，设置一下LD_LIBRARY_PATH，这样的话就不会和当前系统的一些功能发生冲突了。。。

Me Wonderful Me
 

Great people talk about ideas.
Average people talk about things.
Small people talk about other people, and then, sadly, there are the people who love to talk about themselves.

Who do you want to be?

This is Hugh MacLeod's gallery of art, whose cartoon talk about life and many other meaningfull things......

    最近看了一本超级强大的书Embeded Linux Primer，里面介绍了内核调试的一种方法可以通过转储printk日志缓冲区的方法来查看内核的打印内容。开始还有些奇怪，为什么start_kernel中的printk一直不起作用呢？难道是程序没有跳转到这里，但是自己都检查几遍之前的代码了，应该没什么问题。这才知道原来printk在终端设备初始化之前是先把打印的内容暂存到自己的日志缓冲区中的，只有等终端设备初始化后才一起投放到我们面前，所以console_init()函数执行之前我们不会看到任何printk打印的信息，最多只能看到内核自解压时打印的那句"Uncompressing Linux......................."，不过这已经让我兴奋不已了<^_^>，为了定位到程序的出错位置，我首先使用串口控制台的打印函数printascii()，这个函数是.../arch/arm/kernel/debug.S中定义的，非常有趣的是在文件的注释处有这么一段英文描述：

/*
 * Some debugging routines (useful if you've got MM problems and
 * printk isn't working).  For DEBUGGING ONLY!!!  Do not leave
 * references to these in a production kernel!
 */

     看来内核的设计者早就知道我们会遇到“MM problems”了，这些函数足够我们debug用的了，printascii函数还是在内核启动早期的.../arch/arm/kernel/head-common.S中用到过，不过此时MMU已经打开了，怎么还能使用IO地址空间打印东西呢，不用担心，这个在早期的建立页表的函数head.S中的__create_page_tables()中就完成了映射工作，不过需要在内核配置时打开CONFIG_DEBUG_LL配置开关，通过这种方法我定位到了内核死在了setup_arch()->paging_init()->bootmem_init()处。接下来就是通过转储printk的日志缓冲区来显示panic()的信息了，首先我们必须知道日志缓冲区的在内存中的地址，这个可以通过查看System.map中的__log_buf得到，通过查找我得到了这样一条记录c025e018 b __log_buf，其中__log_buf是在.../kernel/printk.c中定义的，还有一个问题就是我们需要将c025e018这个地址转化一下，因为很显然这是一个虚拟地址，然后就可以利用u-boot的工具md打印内存地址上的内容了，md 3025e018，虽然显示的都是ascii码，读起来不是很方便，但是还是能够看到"bootmem alloc of 32768 bytes failed!"的错误信息。。。

    说到了这里，那内核为什么停在了bootmem_init()处了呢？