现象

在进程A的线程s中使用system执行了进程B（后台持续运行），在进程A退出时向守护进程D发送了socket断开信息，但是进程D没有收到消息。在shell中手动重新运行进程A时，进程A中打开设备失败。

调查步骤1-尝试

作为linux入门级选手，尝试在进程A退出后，在shell端kill掉进程B，发现守护进程D即刻收到socket消息。再次手动运行进程A，不会出现打开设备失败信息。

在进程A中不运行进程B，直接在shell中执行进程B。在进程A退出时，守护进程D即刻收到socket消息。进程A再次运行也不会出现打开设备失败信息。

怀疑进程A通过调用system执行进程B，使进程B继承了进程A的某些资源，造成进程A退出后，进程B不释放。在进程A运行期间，查看进程B的父进程为pid为1：init进程，进程A和进程B不属于父子进程关系。

想到解决方法为：在进程A退出时（正常或者异常），进程B都能跟随退出。基于此想法，进行解决方法搜索。

参照网址https://www.cnblogs.com/cornsea/archive/2010/06/08/1754369.html（使用prctl API, 在父进程退出后，让子进程也退出）中说法改写system函数，调用prctl(PR_SET_PDEATHSIG, SIGHUP)，写测试程序，在PC上执行，发现kill掉主进程时，创建的子进程的确可以退出。交叉编译到装置里运行，主进程kill掉后，创建的子进程仍不能退出。

调查步骤2-尝试

步骤1中，使用prctl失败后，继续搜索。https://stackoverflow.com/questions/284325/how-to-make-child-process-die-after-parent-exits How to make child process die after parent exits?。其中提到：

int pipes[2];
pipe(pipes)
if (fork() == 0) {
    close(pipes[1]); /* Close the writer end in the child*/
    dup2(pipes[0], 0); /* Use reader end as stdin */
    exec("sh -c 'set -o monitor; child_process & read dummy; kill %1'")
}

close(pipes[0]); /* Close the reader end in the parent */

待去尝试

调查步骤3-解决

在进程A运行期间，使用netstat -anpl | grep -i 端口号 查看到进程A和进程D的相关信息。等进程A退出后，再次使用此命令查看，进程A的socket被进程B接管。父子进程中，https://blog.csdn.net/carl_wu_/article/details/77976020(Linux中，子进程与父进程的继承关系)，子进程继承了父进程的文件描述符，socket和打开设备都属于文件描述符。system执行的进程虽然父进程id不是其执行进程的id，但其中也调用了fork函数（http://blog.chinaunix.net/uid-29191363-id-4020441.html），应该也符合子进程继承父进程相关资源。基于父子进程继承问题进行相关搜索。

https://zhidao.baidu.com/question/155906659.html C语言在linux如何让子进程不继承父进程的资源

https://blog.csdn.net/anthonytao/article/details/91922026 一个子进程继承父进程所有文件描述符的坑

网址中给出了解决方法，在执行execl系列函数前关闭所有已经打开的文件描述符。因此，问题就转换成了，执行fork后，execl前，关闭所有已打开的文件描述符。

先用简单的方法进行测试，https://bbs.csdn.net/topics/392057956?page=1。在进程A退出后，守护进程D可以收到socket消息，再次运行进程A，打开设备正常。

但每次关闭所有的文件描述符，效果还行，但效率感觉不是很好。网址中http://blog.csdn.net/chrisniu1984/article/details/7050663 （O_CLOEXEC）在打开设备时追加O_CLOEXEC标志，在执行exec时可自动关闭一打开的文件描述符。open时可以追加此标志，但fopen怎么加？

上述简单的方法关闭打开的文件描述符不友好，http://blog.chinaunix.net/uid-317451-id-92698.html（快速关闭所有打开的文件描述符）提供了遍历/proc/进程id/fd目录下逐一关闭方法。待试。

后记

改写system，在fork后开始执行exe系列函数。例如将：system("xterm -hold -e ls")中参数直接表示成execl("/bin/sh", "sh", "-c", "xterm -hold -e ls"), (char *)0)，将会创建两个xterm进程（可以用 top & 替换xterm整条命令），且其中一个为另一个的父进程，若改写成execlp("xterm","-hold","-e","ls",NULL)，将不能正确执行。参考https://www.oschina.net/question/725177_83243?sort=time（关于linux execl函数），需改成execlp("xterm", "xterm","-hold","-e","ls",NULL);或者execl("/bin/sh", "xterm","-hold","-e","ls",NULL);

如何将exec函数传参封装成象system函数传参一样？

问题

在进程A退出时发送的socket消息，守护进程D并未收到，跑哪里了？待调查

https://blog.csdn.net/fengxinze/article/details/6898405

/*******************************************************************************
** Description :  wrap system()
** Parameter   :  void
** Return      :  0 :success;  -1 :fail
** Author      :  Kevin Liu   2015-02-11 
** Remark      :  
*******************************************************************************/
int System(const char* cmd)
{
	int status;  
  
	status = system(cmd); 
	if (-1 == status)  
	{  
		Trace("LGH", "cmd: [%s]\t error: [%s]\r\n", cmd, strerror(errno));
		return -1;
	}  
	else 
	{  
		Trace("LGH", "system() return status = [%d], WIFEXITED(status):[%d], WEXITSTATUS(status):[%d]\r\n",
									status, WIFEXITED(status), WEXITSTATUS(status)); 
		if (WIFEXITED(status))  
		{  
			if (0 == WEXITSTATUS(status)) 
			{  
				Trace("LGH", "run cmd [%s] successfully\r\n  errno:[%d], err-info:[%s]\r\n",
																cmd, errno, strerror(errno)); 
				return 0;
			}  
			else 
			{  
				Trace("LGH", "run cmd [%s] fail\r\n script exit status: [%d],  errno:[%d],err-info:[%s]\r\n", 
													cmd, WEXITSTATUS(status), errno, strerror(errno)); 
				return -1;
			}  
		}  
		else    
		{  
			Trace("LGH", "cmd [%s] exit status = [%d]\r\n  errno:[%d],err-info:[%s]\r\n",
									cmd, WEXITSTATUS(status), errno, strerror(errno)); 
			return -1;
		}  
	}
}


这是改写的，原文链接：http://www.linuxidc.com/Linux/2011-09/42425.htm
 

 
通用的linux提供一个已经编译好的kernel，但是在嵌入式操作系统中，这种方式比较少用。我们将提供一个尽可能简单的kernel configuration，去除我们不需要的功能。我们首先需要选择linux的kernel。
我们可以在http://www.kernel.org/中得到官方（official，也成为upstream或者 mainline）的linux内核版本，他是Torvalds以及全球的其他自愿者提供。虽然2.4的版本仍在很多设备上使用，如果是新的开发应基于 2.6的版本。这些版本通常更关心工作在x86的desktop和server，但是也不会忽略嵌入式设备。嵌入式操作系统和CPU的结构有关，例如 ARM结果，ARM的开发者根据官方的版本，增加他们特定的patch，这些补丁将反馈给Linus，进入官方的版本中。我们选择linux kernel可能是网站社区，有人或者一群人来维护你所选择的架构，例如ARM、PowerPC。如果我们对kernel code有改动，应尽快地反馈，使得你的程序可以在下一版本中沿用，这同时也受到了GPL的要求。
我们也可以从第三方厂家那里得到kernel，虽然是基于上游版本，但是包括了很多的patch提供特别的功能，修订bug，已经有不少修改，它上游的版本可能有很多的不同。这种有点类似我们使用moblin封装的kernel。
当我们选择kernel后，我们对kernel进行configuration，选择所需的部分。对于嵌入式架构，包括下面的选择：Code maturity level options, General setup, Loadable module support, Block layer, Networking, Device drivers, Filesystems, Kernel hacking, Security options, Cryptographic options, Library routines。第一步是选择正确的CPU架构。我们进行配置，可以使用make config, make oldconfig, make menuconfig和make xconfig，都可以在source code那里生成一个.config文件。一般使用menuconfig，对于xconfig某些架构，例如PPC，菜单会有些问题。在上一章讲过使用 cross plateform toolchain的情况，命令如下：$ make ARCH=arm CROSS_COMPILE=arm-linux- menuconfig。
在makefile中有一个参数为EXTRAVERSION，例如设置为-rmk1，则kernel为2.6.29-rmk1，可以用来提供不同版本的区别，例如增加某些模块等等。
接着就是编译，包括kernel image和kernel modules。编译kernel的例子为make ARCH=arm CROSS_COMPILE=arm-linux- zImage ，zImage表示使用gzip的压缩方式，对于x86，还可以是bzImage（表示big zImage，和bz2的压缩没有关系），这一步骤的顺利进行用于检验我们对kernel配置是否正确，也可以检验cross-development工具链环境是否正确。编译好之后，可以编译内核模块，例如：make ARCH=arm CROSS_COMPILE=arm-linux- modules。如果我们希望删除之前处理的内容，包括配置文件，编译的.o文件和kernel img，可以使用 make ARCH=arm CROSS_COMPILE=arm-linux- distclean 命令。在使用这个命令之前，请保存好配置文件img等内容。
编译之后是安装。这个将在第6章和第9张介绍。对于管理多个kernel img，每个包括vmlinux，System.map，.config以及arch/your_arch/boot/下的zImage或者 bzImage。有些架构，例如PPC，有很多boot目录，所以img不一定为arch/your_arch/boot/zImage，可以是arch /ppc/images/vmlinux.gz。建议我们将他们都存放在$(PRJROOT)/images/的路径下。内核模块的安装，包含在 makefile中，缺省的将安装在/lib/modules目录。但是我们使用的是cross的环境，不是要更新本机的内核模块，这点必须要注意。例子：$ make ARCH=arm CROSS_COMPILE=arm-linux- INSTALL_MOD_PATH=${PRJROOT}/images/modules-2.6.20 modules_install 。之后，我们将建立在模块运行中模块所需要的依赖，使用depmod，但是这个命令不使用与cross的环境，我们将从busybox网站中下载 depmod.pl来完成。一些操作的验证，将在我们下一步的实验中进行。
内核错误的一个常见情况的是kernel panic。当系统获取一个严重错误的时候（例如root文件系统位置缺失），他将停止所有的进程，并生成一个kernelpanic消息。对panic 的恢复是系统重启，可以在kernel的boot参数中设定panic=1（1秒后重启）。但是对于实际的运行环境，有时重启是不足够的，需要提醒操作者紧急情况的出现，换句话说我们需要重新定义panic出现后的处理方式。这个在kernel/panic.c中定义，可以另外改写。

1. 前言 
GUI ( Graphic User Interface ) 系统已行之多年，自从苹果的麦金塔计算机问世之后，世界立刻掀起一阵图形化的使用者接口热潮，随之而起的微软 Windows 系统，让这份流行立于不败之地，而人们对计算机生硬的刻板印象也逐渐消逝，由于 GUI 的出现让 PC 更容易的融入每个家庭。
GUI 的系统很多，有我们熟知的微软 Windows 操作系统、苹果计算机的 Mac OS 、UNIX 底下的 X Window System 等 PC GUI 系统，Embedded 领域里头也有不少的 GUI 系统如 QNX Photon microGUI 等等，这些都不是我们所要探讨的主题，本文将把重点置于『 Embedded Linux 』上的 GUI 系统。
GUI 系统本身的复杂度绝对不是一两篇文章所能探讨的，笔者将尽可能的介绍目前较为成熟的几种 GUI 系统架构，帮助建立读者一些基本观念，如要实作则得另辟单元专栏介绍啰。
1.1 GUI 系统的重要性!
• 亲和力
过去的人害怕学计算机，因为 DOS 时代所谓的学计算机常常和背指令划上等号，这是许多人的刻板印象，也是许多学计算机人的痛苦回忆，直到图形接口系统的出现才改变了这样的情况，全拜图形使用者接口的亲和力。
人本来就活在充满 2D 或 3D 的图形世界中， GUI 的出现只是顺从了人的本性，『亲和力』是 GUI 对计算机世界的第一项贡献。
• 丰富了网络世界
如果网络是仅有『 文字 』的世界，相信很多人包括你我，上网意愿恐怕要打个对折，GUI 系统跟网络是相辅相成的，没有太多的因果关系，但却是相得益彰。
• 多媒体应运而生
GUI 系统是多媒体的基础，今天的计算机早都进入多媒体时代了，声光音效让我们的计算机世界更多采多姿。
1.2 成为 Embedded System GUI System 的要素。
嵌入式系统的应用面非常广泛，在导论里头笔者已经提过，很多的场合底下 GUI 都是不可或缺的系统，最显眼的例子当然就是 PDA。一套良好的 GUI 系统可能影响一项产品的成败，由其是在这个注重包装的时代。
与 PC 环境不同的是嵌入式系统通常是安装在体积较小、资源有限的装置，所以能够成为嵌入式的 GUI 系统一定要具备以下的条件：
• 体积小
谈到『嵌入』，真的是除了小还是小，现在 PC 的硬件动不动就是以GB论，以现在Distribution 常用的两片光盘安装片来选择全部安装都还不能塞满整颗硬盘。对于嵌入式硬件来说根本是不可能的奢求，大部分嵌入式系统用的 flash 大都以 16mb 或 32mb 为主，与 PC 简直是天壤之别，所以这样苛刻的环境底下只有把软件尽量压小啰。
牵扯到图形处理的系统都不会是一件轻松的事情，复杂的程度不是三言两语能带过，所以制作嵌入式 GUI 系统的方式大致可分为两大类：
o 精简既有的系统
在某个角度来看，精简既有的系统是最快速的方式，缺点是效能不好控制、体积只能缩小到一定的程度。
o 重新打造一套
最好的情况当然是重新打造一套，优点是系统掌握度高、效能及体积都能调整到最佳状态，但是所需的时间、人力都是很大的成本。
• 耗系统资源少
o 手持式设备
这类嵌入式系统如：PDA、手机，最注重的就是系统资源及省电功能，在省电的前提下 CPU 速度不能太高，运算速度越快越耗电而且散热也会成为大问题。
o 非手持式设备
如：Set Top Box、部份 WebPAD，这类系统主要考虑点在于硬件成本。
o 结论
结论是嵌入式系统的 CPU 都不会比 PC 上的好，内存也是少的多，因此 GUI 系统面临了另一项挑战，必须审慎使用系统资源，不能做无谓的浪费。
• 系统独立
嵌入式系统的一大特色就是硬件差异大，并不像 PC 一般全都 x86 架构。纵使底层硬件差异大，上层 GUI 系统依旧需要表现出统一的接口，所以担任嵌入式 GUI 系统必须尽量与硬件划清界线，最好的情形是在 GUI 系统与硬件中间有一层系统负责隔离，所幸已经有 Linux kernel 可以扮演这个角色。
2. Embedded Linux 底下几种 GUI 系统架构
即使是到了嵌入式环境底下，GUI 整体架构跟 PC Desktop 相去不远，举凡绘图函式库、字型、事件处理..等等课题都是 GUI 系统所要面临到的不管是 PC 或 Embedded，但是嵌入式系统本身有笔者前面章节所提到的种种限制，所以在整体设计上必须较为严谨，必须顾虑的条件更多，彷佛会到 Dos 底下制作游戏的年代，对于软件所占内存锱铢必较。
UNIX 环境底下的图形窗口标准为 X Window System，Linux 算是 UNIX Like 的系统，上头跑的 GUI 系统是兼容于标准 X 的 XFree86 系统，所以 Embedded Linux GUI 系统自然参照现有 PC Desktop 架构具体而微，笔者以 X Window System 架构的思维来介绍各个系统，希望这样的介绍能够让您有清楚的观念。
依照 X 的逻辑，我大致划分了即 X Server ( 包括 Display、Input.. )、Graphic Library ( 底层绘图函式库 )、Toolkitss ( 如 QT、GTK+..等等 )、Window Manager、Internationalization ( I18N )..等几大类来剖析。
底下有几个 X 的专有名词，笔者顺便简略的介绍 X Window System 的架构，如果想要更彻底的了解 X 则必须找寻相关专书阅读。
• X Server
X Window System 架构上有一项特点是别的 GUI 系统所没有的，这个特点就是 Client / Server 架构，请注意这跟一般我们熟知的某某服务器 ( Server 端 ）跟 PC 端 ( Client 端 )相连结的情形不同。唯一类似的是 X Window System 本身也是采网络架构设计。具体而白话一点的介绍，X Client 就是我们在 X 上执行的软件，X Server 则是负责显示、及传递使用者输入事件 ( 包括键盘及鼠标..等等硬件装置的输入 )。
• Graphic Library
我们可以把一幅图案想象成是由成千上万个细微小点所组成，这种小点的单位通常为pixel，在同一平方单位里头这些小点素越高图案就越清晰、画质就越好，专业一点的解释便是分辨率高。我们要设计出一个窗口当然不可能一点一点的画上去啰，这样太过于旷日费时，基于这样的观念我们就会开始设计出高阶一点的函式来帮助我们一些繁琐的步骤，于是可能就会出现画点、画线、画矩形、画圆形、画不规则形、上色..等等的高阶函式。透过这些高阶函式使得程序设计者不用去管画一条线要点几个点以及如何让显示器显示等零零总总低阶的工作，我们称绘图相关的一组函式库为 GUI 的基本 Graphic Library。
• Toolkits
有了点、线、面的函式之后，虽然已经去除大半的无聊工作，但是就开发窗口程序来说，还是显得非常没有效率，怎么办呢？只有继续将构成窗口的抽象组件例如：按钮、滚动条..等等，抽离出来，重新定义一组更高阶的函式库，再配合上一些联系的语法函式就成了 Toolkits 这东西，目前以 QT、GTK+..等较为流行。
• Window Manger
有了 Toolkits 我们可以很轻松的建立窗口软件 ( X Client )，但是每个窗口软件只负责自己软件内的事务，那不同窗口间的沟通、协调例如：窗口的切换、放大、缩小..等等，就没人管了，于是窗口管理员 ( Window Manager ) 就应运而生了。
• Internationalization
国际化通常是我们东方语系国家的人比较关心的议题，但是很多软件一开始都由西方国家所主导开发，因此这点常常受到忽略，这个问题牵扯的层面非常广泛，上从语文的显示、输入，中至语文习惯，下到文字位的处理，完整的解决是必须从头到脚彻底配合才能达成，只处理一半都只能说是一个跛脚的系统。
随着东方国家使用 GNU/Linux 的人口越来越多，I18N 也就日益受到重视，目前底层 libc 部份已经有完整的支持，剩下来便是 GUI 系统的问题，由于处理双位所耗的资源较大、西方国家主导的系统多的情况下，有时候在一些取舍上，I18N 就被牺牲了，整体而言 Embedded Linux GUI 系统在 I18N 的程度通常都没 PC 端的好，只有在有需求时才会特别调校。
上头几点就是笔者藉 X Window System 的分层架构，来指出一般的 GUI 系统所必须具备的功能，虽说 X 架构不错，但坦白说却不甚适用于嵌入式环境底下，因为实作起来实在太过于庞大，因此有很多 Embedded Linux GUI 系统会把上述几点合并，甚至全部绑在一块，当然这样会失去很多弹性与功能，但却也是不得不的作法。
2.1 Qt Embedded
• 概说
Qt 是 Trolltech这家商业公司所开发的一个跨平台FrameWork环境，在 X 底下可以看作是一套功能完整的 UI Toolkits，采用类似 C++ 的语法以及具备对象导向功能，跨平台的特性可以让使用 Qt 撰写的软件，只写一次程序却可以在 Microsoft Windows 95/98/2000, Microsoft Windows NT, MacOS X, Linux, Solaris, HP-UX, Tru64 (Digital UNIX), Irix, FreeBSD, BSD/OS, SCO and AIX 这些平台执行。虽然是商业公司的产品，但是 Qt 走的却是 Open Source 的路子，并遵循同样的游戏规则，除了提供免费下载以外，全部都是开放原始码，非商业用途亦采用 GPL 的版权宣告，著名的 Open Source 『 KDE 』 Project 便是采用 Qt 所发展。
• Qt / Embedded for embedded system
Trolltech 也针对了嵌入式环境推出了『 Qt / Embedded 』产品。与 Desktop 版本不同 ，Qt / Embedded 已经直接取代掉 X Server 及 X Library 等等角色，所有的功能全部整合在一起。
• 特色
o 跨平台
Trolltech 公司承诺会维持同样的 API ，不管是在 Windows 底下的 Qt 或是 X11 底下的 Qt，这样的好处是什么？今天你只要用 Qt 写了一套软件，然后在不同平台下重新编译过就可以立即使用，省掉了不少移植软件的功夫自然也省掉了许多宝贵的时间，这样的概念与 Java 十分接近。
o 模块化设计
模块化设计最大的好处就是弹性，Linux kernel 不也因为模块化而弹性十足，Qt / Embedded 号称最小可以缩到 800 Kb 左右，最多则可以长到 3 Mb ( for Intel x86 )，这样的弹性让 Qt / Embedded 更适合在嵌入式环境底下生存。
o 开放原始码
开放原始码的优点应该是不言而谕的。如果你愿意你可以深入了解 Qt 到底是如何运作的。
o 接口简洁漂亮
安装过 KDE 吧!是不是对它爱不释手，界面真的挺美的。
o 执行速度快
跟 X11 比起来，剃除了许多累赘，Qt / Embedded 执行速度增快许多。
o Trolltech 公司支持
公司采购软件最需要的就是完整的支持，只要您跟 Trolltech 购买 Qt 就可以得到他们最完整的支持。
o 参考文件丰富
Qt 诞生也好几年了，透过 Trolltech 及全世界网友的努力，Qt 的文件可说是相当完整而丰富。
• 参考网站
o http://www.trolltech.com/products/qt/embedded/
2.2 QPE ( Qt Plamtop Environment )
• 概说
Trolltech 公司所推出针对 PDA 软件的整体解决方案，从底层的 GUI 系统、Window Manager、Soft Keyboard 到上层的 PIM、浏览器、多媒体..等等，全部一手包办。
• 参考网站
http://www.trolltech.com/products/qt/embedded/qpe.html
2.3 GtkFB
• 概说
自从 Qt 推出了 Embedded 版本之后，虽然 GTK+ 并非商业公司所发展，但也加紧脚步推出了 GtkFB 项目，这个项目的宗旨当然也是要替 Embedded 系统提出一套基于 GTK+ 的 GUI 解决方案。
与 Qt / Embedded 类似的作法，GtkFB 也跳过 X 层直接与 FrameBuffer 沟通，因此也具有 Qt / Embedded 的几项优点，不过毕竟不是商业软件，在于发展的速度上仍然较为缓慢。
• 特色
o 不需 X Server 直接与 FrameBuffer 沟通
o API 与 Desktop 版相容。
o 采 LGPL 授权方式
o 体积小
• 参考网站
http://www.directfb.org/gtk.xml
2.4 Microwindows
• 概说
Microwindows Open Source Project 成立的宗旨在于针对体积小的装置，建立一套先进的窗口环境，在 Linux Desktop 上透过 Cross Complie 之后，就可以很容易制作出 microwindows 的软件，
• 特色
o 跨平台
o 不需 X Server
o 采用 FLTK Toolkits
o 支持 TrueType 字型
• ScreenShot
o MP3 Player
• 参考网址
http://microwindows.org/
2.5 MiniGUI
• 概说
这是蛮特别的一套 GUI 系统，由大陆的魏永明先生所主持的项目，难得有中国人主导的项目，因为如此所以 MiniGUI 对于中文的支持非常良好。
• 特色
o 支持 GB2312 与 BIG5 字符集，其它字符集也可以轻松加入。
o 支持多种格式字体，例如：TrueType、Adobe Type1等。
o GDI 函数 ( MoveTo、LineTo、FillBox、Rectangle、Circle、TextOut、DrawText ..等 )。
o 可选择具有 Multi-Thread 版与没有 Multi-Thread 的 MiniGUI Lite 版。
• 参考网址
http://www.minigui.org/
2.6 Pure X 架构
• Tiny X Server
Tiny X Server 为 XFree86 Project 的一部分，由 Keith Packard 先生所发展，他本身就是 XFree86 项目的核心成员之一，一般的 X Server 都太过于庞大，因此 Keith Packard 就以 XFree86 为基础，精简了不少东西而成 Tiny X Server ，它的体积可以小到几百 Kb 而已，非常适合应用于嵌入式环境之中。
• 弹性大
以纯 X Window System 搭配 Tiny X Server 架构来说，最大的优点就是弹性与开发速度，因为与 Desktop 的 X 架构相同，因此相对的很多以 Qt、GTK+、FLTK..等等所开发的软件可以很容易的移植上来。
虽然移植速度快，但是却有体积大的缺点，由于很多软件本来是针对 Deskop 环境所开发，因此无形之中功能都比较多样，有些并不适用于嵌入式环境，因此 『 调校 』 变成为采用此架构最大的课题，有时候重新改写都可能比调校所需的时间还短。
3. 网络资源
• Embedded Linux 新闻大本营
http://www.linuxdevices.com/index.html
http://www.pocketix.com/
• Linux base PDA Project
http://www.trolltech.com/products/qt/embedded/qpe.html
http://microwindows.org/
http://www.pocketlinux.org/
http://familiar.handhelds.org/
 
转载地址：http://www.study-area.org/linux/embedded/articles/Embedded_Linux_GUI/Embedded_Linux_GUI.html#toc1