设备调试到了后面，项目里常常会陆续补上一些自己写的命令，比如用来查看业务运行状态、打印驱动的统计信息、清理缓存，或是手动触发一次测试流程。VxWorks的Shell本身就具备这种扩展能力，只不过不同解释器的用法很容易被弄混。C解释器更贴近于直接调用函数入口，而命令解释器则支持带命令名称、帮助说明和参数解析规则的完整命令。在动手扩展之前，得先搞清楚目标板当前用的是哪一种Shell，等注册完成了，也要回到对应的入口去验证。VxWorks 7 SDK依然支持DKM、RTP和共享库，其中DKM跑在内核态，可以动态加载到目标系统里。

　　一、VxWorks Shell命令怎么扩展

　　Shell命令扩展可以分成两类来处理。临时的调试函数只要能被目标系统找到，直接从C解释器调用就行；需要提供固定的命令名、帮助信息和参数解析时，再用命令解释器的注册接口。这两种方式都能用，但写法和检查入口并不一样。

　　1、确认扩展方式

　　先在【串口终端】观察当前的提示符，再试着输入【cmd】切换到命令解释器，然后根据实际需要，决定是保留函数调用形式，还是注册一条独立命令。

　　在VxWorks 7 SDK的运行示例里，输入cmd之后就会进入命令Shell。C解释器很适合直接调用那些已经进了内核符号表的函数，命令解释器则更符合常见终端的操作习惯，能组织好命令名和参数。要是项目只是临时查一下问题，就没有必要额外再包一层命令出来。

　　2、准备命令处理函数

　　围绕【命令处理函数】整理好参数的读取、返回值和错误提示，并把需要暴露给Shell的入口放进DKM或内核工程里面。

　　采用命令解释器注册方式时，处理函数通常有两种形式。opt字段为空的时候，函数就按照argc和argv来接收参数；opt字段不为空时，Shell会根据选项字符串先完成解析，再把结果交给处理函数。命令结构里还可以填上简短说明、完整说明和调用格式，方便以后用help来查。

　　3、先添加主题再注册命令

　　初始化阶段先调用【shellCmdTopicAdd】，接着用【shellCmdAdd】注册单条命令，命令较多时再改用【shellCmdArrayAdd】集中加进去。

　　命令解释器是按照topic来组织命令的。要是topic还没建好，就直接调用shellCmdAdd或shellCmdArrayAdd，就会返回ERROR，并给出S_shellInterpCmdLib_UNKNOWN_TOPIC这样的提示。项目里比较常见的写法，是准备一个静态的命令数组，再由初始化函数一次把主题和命令都注册好。shellCmdTopicAdd只保存主题名称和描述字符串的指针，所以这类字符串不要放在那些会退出的局部作用域里面。

　　4、加载模块并执行初始化入口

　　通过【wrdbg】执行【module load】把DKM加载进来，再回到【串口终端】调一下模块的初始化函数，确认注册动作已经真正执行过了。

　　光把注册函数写到源码里还不够。动态模块需要先进入目标系统，初始化入口也必须被调用到。在VxWorks SDK的DKM流程里，模块可以用module load加载进来，再在串口控制台用lkup去搜索入口函数；如果检索结果为空，就说明符号还没进到内核符号表里。

　　二、VxWorks Shell命令注册后为什么看不到

　　命令没有显示出来，一般不是因为命令处理函数本身写错了，而是注册链路里少了一步。排查的时候不要直接去改函数逻辑，先看一看解释器、返回值和模块状态，往往几分钟就能把问题卡在哪一层定下来。

　　1、当前解释器不匹配

　　命令注册完成后，先在【串口终端】输入【cmd】，再用命令解释器的帮助入口检查一下，自定义命令是不是已经出现了。

　　注册到命令解释器里的东西，不会自动变成C解释器中的普通函数名。反过来也一样，能在C解释器里直接调的函数，并不代表它就进了命令列表。目标板重启、脚本切换了解释器，或者远程会话重新连上之后，都得重新确认一下当前Shell的类型。VxWorks Shell本身就支持不同的解释器，命令解释器和C表达式解释器是两套入口。

　　2、注册返回值被忽略

　　给【shellCmdTopicAdd】、【shellCmdAdd】和【shellCmdArrayAdd】都单独记一下返回值，一旦出现ERROR就立刻把errno打出来，不要让系统继续安静地往下启动。

　　topic名写错了、命令名不合规范、引号没对上，或者内存申请失败，这些事情都会把注册动作打断。代码里要是没去检查返回值，启动日志看起来好像一切正常，可Shell里就是找不到新命令。批量注册的时候还得留心数组的结束标记，shellCmdArrayAdd要求数组末尾的cmdFullname必须为空。

　　3、初始化入口没有运行

　　先用【lkup】搜一下注册函数和处理函数，再结合【启动日志】确认初始化入口是不是已经被调用到了。

　　DKM加载成功，只说明模块已经进了系统。注册函数要是没被执行，命令表依然不会发生变化。那些静态编译进VIP的模块也存在同样的问题，源码已经参与构建了，并不等于初始化入口就一定挂进了启动流程里。排查的时候，可以在注册函数开头加一条简单的日志，别光凭模块文件的状态去判断。

　　4、命令解释器没有纳入镜像

　　回到【VIP配置】里核对一下Kernel Shell和命令解释器相关的组件，再重新生成镜像，观察启动阶段Shell初始化有没有完成。

　　有些精简过的镜像，只保留了很有限的调试能力。这时候处理函数可能已经能通过符号表找到了，但命令注册所依赖的解释器并没有准备好。不同VxWorks版本和项目模板里的组件名称可能会有些差异，实际配置还是要以当前版本的组件说明和生成结果为准。

　　三、VxWorks Shell命令扩展后应该怎样验证

　　命令能显示出来，只能说明注册动作已经做完了。调试类命令通常会接触到共享状态、驱动资源和任务上下文，验证阶段还要注意参数边界和重复注册，免得排查工具反过来干扰系统的正常运行。

　　1、分别验证显示与执行

　　先进到【cmd】解释器确认命令能被检索到，然后分别用一组正常参数和一组错误参数，观察返回值和提示内容。

　　命令入口存在、参数解析正常、异常输入能够退出，这三项需要分开来看。特别是那些会改动设备状态的命令，不要只试成功路径；参数没给、输入越界，或者对象还没初始化的时候，也应该给出清晰的结果。

　　2、检查重复加载表现

　　完成一次【module load】和注册以后，再照样执行一次相同的加载流程，看看会不会出现重复命令、主题冲突，或者资源残留。

　　开发阶段里经常要反复卸载和加载DKM。注册函数要是没处理重复调用的情况，第二轮调试时就可能冒出异常。注册信息如果涉及需要长期保存的字符串和命令结构，建议用静态存储，并把初始化动作控制在明确的生命周期内。

　　3、保留基础诊断入口

　　给新增的命令准备【help】说明，并把【lkup】、【启动日志】和注册返回值记录都保留下来，方便后续版本继续核对。

　　Shell扩展一般是跟着驱动和业务模块一起变化的。命令名称、参数格式和适用状态写清楚之后，现场排查时就不用再回头翻代码了。碰上命令莫名其妙消失的情况，也能很快判断出，到底是模块没加载、初始化没执行，还是当前会话还停留在错误的解释器里。

　　总结

　　VxWorks Shell扩展首先要分清函数调用和命令注册这两条路。临时调试函数可以靠符号表直接调用，正式命令则要先建好topic，再通过shellCmdAdd或shellCmdArrayAdd完成注册。命令看不到的时候，就按照解释器类型、接口返回值、初始化入口和镜像组件这四层一层一层去核对，这比直接去改动处理函数更容易把原因找出来。