有矢而发,触类旁通[内核学习的方法论]<强烈推荐>

本文围绕Linux内核研究展开,阐述研究目的,指出研究内核可把握创新主动权、深层次理解Linux;提到国人研读内核大多处于读的境界,最终应走向开发;还强调研究内核的态度,要结合日常问题触类旁通,且需工具和资料辅助。
一.研究内核的目的
欲举其事,先正其道。要谈论内核的研读以及交流心得,前提必须得有一个恰当准确的目的,方能收获良多。
很多人都有这样一个疑惑,为什么要研究内核呢?我们又不是内核开发者(或许你将来就会成为Linus的助手:-)。此言差矣,众所周知,Linux包含两 层含义,一是内核,二是发行版本,前者乃核心精华,后者则是应用方案,二者皆不可废。知前者而略后者,思而不学也;略前者而知后者,学而不思也。

学习是循序渐进的,我们学习Linux,首先接触的就是各具特色的发行版本,简单轻松地入门,在学习的过程中逐渐对Linux框架有了一个初步的认识,浅 白地说,就是懂得了Linux世界的游戏规则。在你自身能力提高的同时,你会发现,进步的速率似乎在下降,为什么呢?那是因为你开启的只是自己的记忆力而 非智力,游戏规则是核心的高层封装,它给予用户乃至程序员的接口是友好的(相信很多人都陶醉于unix的工具哲学吧),而这类接口经多年的黑客熏陶,已经 变得十分成熟,我等只需识记便可。举个例子吧,发行版本之间最大的差异就是它们各自的FHS(文件目录框架)以及软件包管理机制,如gentoo的 portage(port树)以及emerge,再如Debian的apt-get,用户只要精通此二处,即可在该发行版本的世界里驰骋无束,而精通的途 径却都一样,那就是识记规则。当你已经对这些规则滚瓜烂熟时,你会发现,自己只是从用户角度看问题,而不是从开发者的角度看问题,两者的差异在于你在 Linux世界里是否具有创新力。

对比国内外的Linux开源社区,不难发现,我们的水平依然很低,很多创新点都是外国开源社区所占据的,我们只能跟着走,处于被动的局面。还是举例来说明 问题吧,比如你是一个lfs爱好者,初学者则按lfs文档行事,而老鸟们呢,则参阅lfs hints来改造自己的系统,殊不知,此二者都非国人所力,lfs文档是外国人开发的,lfs hints也是外国人写的。在这里并不是说我们不应该引进技术,而是从中看到,我们的确缺乏创新力;再比如新内核采纳的udev(大家应该不会陌生吧), 它只是一个逻辑I/O层规则,乃是devfs进化而来,大家同在开源社区下学习,为什么外国人能思考出创新的udev呢?归根到底,那是我们不重视最底层 的研究,立足于高层封装看问题,与使用微软的玩具软件何异?我们老是谈论要自己的发行版本,可是有没有想过,发行版本不仅仅是把现成的内核用shell和 X包装起来而已,如果是这样的话,redhat也不会成为世界上最流行的发行版本之一(redhat在开源社区大多数项目中都占有一席位,每每以创新技术 来推出新的发新版本,革新的NPTL线程库就是一个好例子)。


可见,立足于内核看问题,目的有二:
1.学一当十,把握创新的主动权
2.知其然而知其所以然,从深层次理解Linux,使之在发行版本的日常操作能触类旁通,游刃自如


二.研究内核的境界
-->-->开发
现在国人研读内核的境界大多在于(包括我自己:-),而我们的最终境界是开发,也就是成为内核的开发者之一,这样才真正使中国的Linux事业独立自主!

三.研究内核的态度
Linux内核发展了十年有余,体系变得十分庞大,可谓盘根错乱,我们读它,往往很难直接掌握全局,结合我们的实际情况,最好是从日常使用Linux发行 版本的过程中,遇到一些很奇妙的问题,就应该结合它来研读内核的相关项,触类旁通。比如说,开机遇到kernel panic的问题,我们就应该找到,在init/main.c中的init函数就有这样一句话,然后顺着这个思路找出解决办法,最终发现原来必要的文件系 统模块必须编译进内核(自举性矛盾),又比如说,我们要改造发行版本的运行级别脚本,就应该注意到,有些脚本是运行在内核态的(如linuxrc),大多 数脚本是运行在用户态的(rcX.d),了解了大方向,就好编码了。
游击散打,逐渐包围大中心

当然,内核研读还得有好用的工具辅助才行,还要有资料(站在巨人的肩膀上,看得更远嘛)
有矢而发,触类旁通
makecpt [WARNING]: haline is a discrete CPT. You can stretch it (-T<min>/<max>) but not interpolate it (-T<min>/<max>/<inc>). makecpt [WARNING]: Selecting the given range and ignoring the increment setting. c:\Users\ym\Desktop\syy\gmt begin map pdf,png.bat: line 35: bc: command not found c:\Users\ym\Desktop\syy\gmt begin map pdf,png.bat: line 36: bc: command not found mapproject [ERROR]: Cannot find file 103.8/36.7 c:\Users\ym\Desktop\syy\gmt begin map pdf,png.bat: line 40: bc: command not found mapproject [ERROR]: Cannot find file 103.8/36.7 c:\Users\ym\Desktop\syy\gmt begin map pdf,png.bat: line 41: bc: command not found mapproject [ERROR]: Cannot find file 103.8/36.7 c:\Users\ym\Desktop\syy\gmt begin map pdf,png.bat: line 42: bc: command not found mapproject [ERROR]: Cannot find file 103.8/36.7 gmt.exe [ERROR]: Shorthand -R not allowed for modern GMT mode. gmt.exe [ERROR]: Shorthand -J not allowed for modern GMT mode. basemap [ERROR]: Option -L: Not allowed for Cartesian projections basemap [ERROR]: Option -L: No fancy map scale modifier allowed for Cartesian projections -L[g|j|J|n|x]<refpoint>+w<length>[e|f|M|n|k|u][+a<align>][+c[[<slon>/]<slat>]][+f][+j<justify>][+l[<label>]][+o<dx>[/<dy>]][+u] Draw a map scale centered on specified reference point. Positioning is specified via one of four coordinate systems: g: Give <refpoint> in map coordinates. j: Set inside-the-box <refpoint> via justification code (BL, MC, etc). J: Set outside-the-box refpoint> via justification code (BL, MC, etc). n: Give <refpoint> in normalized coordinates in 0-1 range. x: Give <refpoint> in plot coordinates. All systems except x require the -R and -J options to be set. Refpoint modifiers: +j Append 2-char <justify> code to associate that anchor point on the map scale with <refpoint>. If +j<justify> is not given then <justify> will default to the same as <refpoint> (with j), or the mirror opposite of <refpoint> (with -J), or MC (otherwise). +o Offset map scale from <refpoint> by <dx>[/<dy>] in direction implied by <justify> [0/0]. Set required scale via +w<length>, and (for geographic projection) append a unit from e|f|k|M|n|u [km]. Other scale modifiers are optional: +a Append label alignment (choose among l(eft), r(ight), t(op), and b(ottom)) [t]. +c Control where the map scale should apply. If no arguments we select the center of the map. Alternatively, give +c<slat> (with central longitude) or +c<slon>/<slat> [Default is at scale bar placement]. +f Draw a "fancy" scale [Default is plain]. +l Set scale <label> to use [By default, the label equals the distance unit name and is placed on top [+at]. Use the +l<label> and +a<align> mechanisms to specify another label and placement. For the fancy scale, +u appends units to annotations while for plain scale it uses unit abbreviation instead of name as label. +u Append unit set by +w to all distance annotations (for the plain scale, +u will select unit to be appended to the distance length. +v Select a vertical scale instead for Cartesian plots.这警告的原因如何处理
05-22
### 解决GMT工具在`makecpt`和`mapproject`中的常见警告与错误 #### 问题描述 用户提到在使用GMT工具时遇到多个警告和错误,具体包括以下几个方面: 1. **离散CPT无法插值**:尝试对离散色彩映射表(CPT)进行插值操作失败。 2. **`bc`命令未找到**:某些计算依赖于`bc`命令,但在环境中未能识别该命令。 3. **文件找不到**:指定的输入或输出文件路径不存在。 4. **现代模式下的简写选项不被允许**:在GMT现代模式下,部分传统简写选项不再有效。 5. **地图比例尺选项错误**:在Cartesian投影中误用基图(basemap)的比例尺选项`-L`。 以下是对这些问题的具体分析及解决方案。 --- ### 离散CPT无法插值 如果用户试图对一个离散CPT文件进行插值操作,则可能会收到类似以下的警告消息:“Discrete color table cannot be interpolated”。这是因为离散CPT文件的设计初衷并不支持平滑过渡的颜色变化。要解决此问题,可以采取以下措施之一: 1. 使用连续型CPT文件替代离散型CPT文件[^6]。 ```bash gmt makecpt -Cviridis -T0/100/1 > continuous.cpt ``` 2. 如果必须保留离散CPT文件,则需明确告知GMT无需插值操作。例如,在绘图过程中避免传递可能导致插值的操作参数。 --- ### `bc`命令未找到 当脚本中涉及数值运算时,可能调用了外部工具如`bc`来进行浮点数计算。然而,如果运行环境缺少`bc`命令,则会抛出“command not found”的错误。对此有两种解决办法: 1. **安装`bc`工具**:确保系统已安装`bc`软件包。对于基于DebianLinux行版,可执行以下命令完成安装: ```bash sudo apt-get update && sudo apt-get install bc ``` 2. **改用内置shell算术扩展**:许多简单的数学运算可以直接由Shell解释器完成而无需借助额外程序。例如: ```bash half_length=$(( length_km / 2 )) echo "${half_length}" ``` 注意,这种方法仅适用于整数运算;若需要处理小数点精度较高的情况,仍然推荐使用`bc`或其他专门设计用于科学计算的语言库。 --- ### 文件找不到 此类错误通常源于指定路径有误或者目标资源确实缺失。为了避免这类问题生,请遵循以下建议: 1. 明确验证所有引用文件的实际存在状态及其访问权限设置是否恰当; 2. 对绝对路径名保持敏感态度——尤其是在跨平台迁移项目期间更应注意调整相应配置项使之适应新主机的工作目录结构布局特点; 3. 当不确定某特定数据集的确切存储位置时,不妨利用通配符(*)辅助定位符合条件的第一匹配对象作为临时应急手段。 示例代码片段展示如何动态获取第一个满足条件的数据源实例: ```bash data_file=$(ls *.gmt | head -n 1) if [[ ! -z "$data_file" ]]; then echo "Using data file: ${data_file}" else echo "No suitable data files found!" fi ``` --- ### 现代模式下的简写选项不被允许 自GMT 6.x系列引入现代化工作流程以来,默认启用的新一代交互范式强制要求开者显式声明全局范围内的区域边界(-R)、投影类型(-J)以及其他核心属性定义语句,从而彻底摒弃以往那种隐含默认行为的传统做法。因此,一旦切换至Modern Mode之下运作的话,任何企图沿袭旧习继续采用简化形式表达这些必要组成部分的做法都将遭到拒绝,并伴随相应的诊断信息提示用户修正语法表述方式直至符合最新标准为止。 正确示范如下所示: ```bash gmt begin myplot pdf modern gmt basemap -R10/70/-3/8 -JX10c/5c -Ba -B+t"My Title" gmt end show ``` 上述例子清晰地展示了即便是在最基础层面创建空白画布这样的简单任务当中也需要严格按照规定顺序逐一罗列所需各项细节内容才能顺利完成整个过程。 --- ### 地图比例尺选项错误 最后关于Basemap组件里的Scale标记渲染环节存在的争议焦点主要集中在Cartesian坐标系环境下非法运用原本专属于Geographic场景才适用的功能特性之上。具体表现为尝试通过添加类似于'-Lg...'之类的开关指令期望达到自动标注实际物理尺寸距离的效果却意外触了兼容性冲突异常状况的生。 针对这一现象的有效规避策略便是严格区分不同类型的投影体系之间本质差异所在之处进而合理选用适配各自特性的专属API接口函数集合来达成预期目的。比如下面这段经过优化改造后的版本就很好地解决了前面提及的那个典型应用场景需求案例: ```bash gmt basemap -R0/100/0/100 -JX10c -Bxa10f1+l"Distance (km)" -Bya5f1 -BWsne -Lf50/0/50/100+k+f+u"k" ``` 在这里我们巧妙地采用了水平方向上的固定间隔刻度线配合垂直维度上更为精细划分的小节段组合而成的整体框架结构再加上末端附加说明文字标签共同构成了最终呈现出的理想效果画面。 --- ### 总结 通过对以上几个方面的深入剖析可以看出,每一个看似孤立无关联的技术难题背后往往隐藏着深层次的原因链条等待挖掘探索。只有当我们能够站在更高的视角俯瞰全局脉络走向之时才能够真正做到举一反三触类旁通自如应对各种复杂局面挑战从容化解各类棘手困境难关。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值