
软硬件的基础知识一定要扎实,比方中断的原理,串口通信的原理什么的。。。
最重要的还是你自己在这一年中做过什么,把你自己做过的东西讲清楚的话,
一般人家HR就能判断你这个人到底肚子里是不是有真材实货,不要像很多
华而不实的人一样,自己什么代码都没写过的项目也往简历里面凑,这样没好处。
至于薪水,我们相信做驱动开发的工作永远也不会差,关键还是得能在工作
中出成绩才能对得起人家的高薪水。另外除了薪水之外,公司能具有的工作学习
气氛更加重要,毕竟,你也只有一年的工作经验,还是处于经验的积累期。
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
杭州巨立安技术(JulianTec),专注于提供Linux相关的项目研发和技术培训服务。
首先要定义,我所认为的一个优秀的驱动开发工程师,应该具备什么样的能力,这里列一下按照从易到难的顺序,个人认为应该会有几个方面的要求吧:
能够独立完成驱动的功能开发任务
能够分析和优化驱动的性能,针对特定硬件扬长避短
能够充分了解模块相关软硬件能力、发展方向,辅助应用工程师最大化利用硬件能力
能够辅助硬件工程师规划硬件设计,预防问题,谋求功能模块的最佳方案
能够协助定义系统架构,合理规划软硬件,谋求产品实现的最佳方案
作为一个驱动工程师,很多时候不是完全从头开发一个完整的子系统,而是针对特定硬件和平台移植驱动,增加功能,解决Bug等等,如果从这方面外在的表现来看:
解决问题的境界,大概会有这么几个阶段:
不知道哪里存在BUG
不知道如何解决BUG
知道如何解决BUG
知道如何发现BUG
知道如何规划BUG
知道如何发现BUG(而不是撞上BUG)其实并不简单,需要你对系统有足够的了解,能够察觉可能出问题的地方。而规划Bug更难,需要你能对问题的轻重缓急做出准确的判断。没有的完美的世界,只有适当的取舍,规避和预防。
而从解决问题过程的角度来看,我认可以分为几个阶段:
BUG发生 ->大量跟踪调试代码 ->终于发现并解决BUG
BUG发生 ->理论推测可能原因 ->迅速定位并解决BUG
阅读代码 ->预测可能出现的BUG ->证实并解决BUG
号称能光凭瞄一遍代码就找到问题的高手,我想我是没希望了。
应该具备怎样的素质
那么要达到上诉最佳境界,需要具备和发展哪些素质和能力呢?
足够的硬件知识
能看简单的原理图,能够分析硬件异常的可能原因,能够使用常见的硬件调试工具,我想这是做为优秀的驱动工程师,区别与其它软件工程师,所不可避免、必须具备的专业素质。当然取决于你具体从事的工作,对这方面的要求不尽相同。
对于驱动开发者来说,不了解所开发驱动外设的硬件原理和相关背景知识,也许很多时候,也能够完成一些移植,修补的工作任务,但这就好比无源之水,无根之木,我相信是很难走远的。
多多益善的 *** 作系统知识
做驱动开发,特别是纯粹的外设的驱动移植工作,刚开始的时候,也许你并不需要了解很多 *** 作系统本身的知识(像内存管理,进程调度,锁,各种内核子系统的原理框架等等),也能顺利完成手头的一些工作。
但是,如果一但需要优化驱动,需要完善软件框架,或者是遇上疑难问题需要跟踪解决,对 *** 作系统,内核本身的了解,就体现出它的价值了。
对于Linux内核驱动开发者,尤其如此,首先,代码是完全开源的,你有条件去了解背后的运行机制,其次,Linux内核和各个组成子系统总是在迅速的进化发展中,不进则退,你也有必要跟上时代发展的脚步。
强烈的好奇心,持续的热情
如果驱动开发不仅仅是你的爱好,更是你养家糊口的途径,我想,很多时候,你大概不会有机会专注于一两个你最有经验的模块的开发和维护。随着能力的成长,势必会要求你接触和掌握越来越多的各式各样的驱动模块的开发。
对于这件事,包括我自己,有时候大概都会有如下几种反应:
哇,原来的工作做太久了,太乏味了,很高兴能做不同的工作。
啊?又要做别的模块啊?我手头的工作已经太多了!
这个模块没意思,我不想做。
相信多数有志青年们都是第一种表现了 8 )不过,有些时候,我发觉,很多人的这种热情其实并不持久,一个新的模块没做多久,就再次厌倦了,是已经炉火纯青了么,未必,或许只是修改了几个BUG以后不甚其烦。很多时候,我面试前来求职的工程师时,发现简历上这个也做过,那个也做过,但是一但问到解决了什么问题,所做过的驱动,框架、流程、原理之类的问题的时候,就一问三不知了。
我觉得如果自己的目标是优秀,那么最起码的标准应该是对具体驱动模块相关的子系统的整体工作流程,框架,具备足够的好奇心,乐于去了解和学习,而不仅仅是为了完成任务而工作,否则的话,很难积累下扎实的经验和技术。
清晰的逻辑思维能力
这一点,也许是个软件开发人员都应该具备吧,不过,做为驱动开发工程师来说,有时候,大多数情况下,工作的硬件环境并不是完美的,遇到问题需要分析判断错误的原因是硬件问题还是驱动Bug,这时候,清晰的逻辑思维能力尤其重要。
良好的工作习惯
大多数人都不是天才,要成为优秀的开发工程师,一需要持续努力,二需要时间积累经验,而这过程中,很重要的一点,就是要有良好的工作习惯。譬如,注意设计文档的维护,对工作中遇到的问题的记录,过往经验的及时记录,适当的软件开发流程等等。文档工作,可能很多人很不愿意去做,它的确很花费时间。不过,唉。。。老啦,好记性不如烂笔头啊 8 )。当然,其实设计文档更多的是为你提供思考的机会,而过往经验的总结,也可以起到和大家交流技术,共同进步的目的。
英语
这个也是必须的啦,没有办法,邮件列表,技术文档,社区,精通英语肯定是很大的优势,做开源项目尤其如此。阅读各种Spec标准文档之类的速度还是很重要的。阅读无障碍是一回事,能和母语一样一目十行,那才爽呀,唉,人生苦短,效率啊!光读文档,就不知道要比老外多花多少时间。。。。
了解更多开源相关,去LUPA社区看看吧
在 Linux 开发时,我们经常会看到一些形如 xxx.so 的名称出现,其中 so 是 Shared Object 的缩写,即可以共享的目标文件,也就是我们所称为的动态链接库,和在 Windows 下大家玩 游戏 时遇到的 xxx.dll 错误中的文件是一个类型的。
面试中经常会问到以下问题:
库是写好的现有的,成熟的,可以复用的代码。现实中每个程序都要依赖很多基础的底层库,不可能每个人的代码都从零开始,因此库的存在意义非同寻常。本质上来说库是一种可执行代码的二进制形式,可以被 *** 作系统载入内存执行。
库有两种:
在一个程序的编译过程中,分为以下几个步骤: 预处理 , 编译 , 汇编 , 链接 。本文中讨论的链接库就是针对最后一个步骤「链接」而言的。
动态库和静态库的区别
左图为静态链接库,右图为动态链接库
对于静态链接库而言在链接阶段,会将汇编生成的「目标文件.o」与引用到的库一起链接打包到可执行文件中。因此对应的链接方式称为静态链接:
静态链接可以理解为最后生成了一个「单文件免安装绿色版」的程序,优点在于移植的时候只需要移动这一个文件,缺点在于文件体积非常大,为了解决这样的问题,就有了动态链接库。动态链接库在程序编译时并不会被连接到目标代码中,而是在程序运行时才被载入。
动态库连接到系统空间,如果多个程序连接了同一个库,那么只需要一份,优点在于编译程序的时候不会将对应的库文件全部打包在生成的程序中,而是保留了到对应库的链接,缺点就是移植的时候如果只移动了对应的程序没有安装相关的库的话,就会看到类似以下喜闻乐见的结果了。
在 Linux 下一个动态库有y三个不同名字的文件组成:
当程序在内部列出所需要的链接库时,仅仅使用 soname。当你创建一个链接库时,使用 real name。安装一个新的链接库时,把它复制到一个DLL文件夹里,然后运行程序 ldconfig。ldconfig 检查存在的 real name 文件,并且创建指向它符号链接 soname 文件。可能大家比较常见到的有 libsodium 等。
有了上面关于库的一些基础知识之后,我们可以开始尝试创建一个动态库来供程序使用了。
比如我们有一个求最大值的函数 max(int a,int b,int c) ,放在文件 max.c 中文件内容如下:
可以通过:
将其编译为共享库,-fPIC是编译选项,PIC是 Position Independent Code 的缩写,表示要生成位置无关的代码,这是动态库需要的特性; -shared是链接选项,告诉 gcc 生成动态库而不是可执行文件。为了让用户知道我们的动态库中有哪些接口可用,我们需要编写对应的头文件,比如可以写一个 max.h :
设置一个驱动函数来测试我们编写的动态库:
通过 gcc test.c -L. -lmax来生成 a.out,其中-lmax表示要链接 libmax.so,-L.表示搜索要链接的库文件时包含当前路径。
但是这样直接运行的话,会出现一个错误:
由于 Linux 是通过/etc/ld.so.cache文件搜寻要链接的动态库的,而 /etc/ld.so.cache 是 ldconfig 程序读取 /etc/ld.so.conf 文件生成的,本次使用的动态库 libmax.so 并不在对应的目录下,就会导致程序无法找到对应的动态链接库,这样我们的解决方法有二:
小结
动态链接库是各个系统中的一个重要的组成部分且在 Linux 开发相关领域中尤为重要,也是一个面试的高频考点,除了动态链接库以外,还有以下相关知识也是高频考点,在面试前一定要准备好:
本文作者:Nova Kwok
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)