• prtos, info 正在进行当中，已经完成70%的进度^_^
• 小赵 您好，当前是否支持ARM v8指令集的芯片？
• prtos, info 目前从事编译器前端相关的工作。
• prtos, info 在确定内核工作队列溢出的情况下，首先要复现这个场景，然后具体问题，具体分析，我能想到的排查手段是： 1. 监控工作队列 使用监控工具：VxWorks 提供了多种监控工具和API，可以用来实时查看系统状态。例如，kernelShow 可以显示内核状态信息，包括任务、内存、消息队列等。 任务监控：使用 spy 和 tt 命令监控任务的执行情况，查看是否有任务长时间阻塞或频繁出现，可能导致工作队列的堆积。 2. 检查系统日志 内核日志：检查 VxWorks 的内核日志，查看是否有与工作队列相关的错误或警告信息。 调试日志：在内核代码中添加调试日志，记录工作队列的使用情况。可以记录入队和出队操作的频率和队列长度。 3. 调整队列大小 配置参数：根据需求调整工作队列的大小。例如，可以增加工作队列的深度以适应更高的负载。 代码配置：在代码中修改工作队列配置参数，重新编译和部署系统。 4. 分析任务优先级和执行时间 任务优先级：确保高优先级任务不会被低优先级任务阻塞，导致工作队列堆积。 任务执行时间：检查任务的执行时间，避免长时间运行的任务占用工作队列资源。可以通过优化算法或拆分任务来减小单个任务的执行时间。
• 稀里哗啦 大佬现在从事什么领域的工作？
• 稀里哗啦 和大佬您是同年上的研究生，应该是同龄人。 在国内JG这些年把自己整废了，和您的差距可以算是十万八千里。 由衷的膜拜。 最近遇到一个VxWorks下内核工作队列溢出的问题，想请教下大佬，有何排查建议？
• lixingshuai 已经解决。
• lixingshuai 博主：我运行到这里就卡住了，可以按Ctrl+a切换，但没有后续的内核打印信息，您可以帮忙解答一些吗？ (XEN) No support for ARM_SMCCC_ARCH_WORKAROUND_1. (XEN) Please update your firmware. (XEN) *************************************************** (XEN) 3... 2... 1... (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) (XEN) *** LOADING DOMU cpus=1 memory=85ee0KB *** (XEN) Loading Domd1 kernel from boot module @ 0000000053000000 (XEN) Loading ramdisk from boot module @ 0000000058000000 (XEN) Loading zImage from 0000000053000000 to 0000000040080000-000000004084cbcc (XEN) Loading dom0 initrd from 0000000058000000 to 0x0000000048200000-0x000000004831c20d (XEN) Loading dom0 DTB to 0x0000000048000000-0x00000000480004d5 (XEN) Freed 312kB init memory.
• prtos, info Good catch!
• Joy 在出现 FDT_ERR_NOSPACE 报错的对应fdt 指令前，执行 fdt resize ，可以理解为扩充了 dts blob 的空间，然后再接着用fdt命令其他指令就OK了
• prtos, info 这句话的意思是说，当前任务被阻塞时，会设置WIND_PEND位， 此时如果timeout也被设置的话，WIND_DELAY位也会被设置。而当前任务的WIND_READY位一直处于设置状态，不会被清除。 VxWorks的任务的执行态和就绪态和以下这些位的设置，不是一一对应的。WIND_READY只是表示该任务具有运行的资源，并不是任务正在CPU上运行(执行态)。 #define WIND_READY 0x00 /* ready to run */ #define WIND_SUSPEND 0x01 /* explicitly suspended */ #define WIND_PEND 0x02 /* pending on semaphore */ #define WIND_DELAY 0x04 /* task delay (or timeout) */ #define WIND_DEAD 0x08 /* dead task */
• prtos, info VxWorks5.5是支持动态加载的，“单态操作系统就是对安全性的放弃，追求实时性”这句话的后半句是对的。VxWork5.5整个系统(包括Wind内核)均运行在处理器的特权模式，内核服务以函数调用的形式存在，没有上下文切换的开销；后半句“单态操作系统就是对安全性的放弃”，某种程度上也是对的，只不过单态RTROS，将系统的安全性寄托在应用程序没有设计缺陷上，即寄托在应用程序开发者的素养上。
• prtos, info 站点不能自动发送邀请码，我已经将邀请码发送到你的邮箱277922995@qq.com， 请查收。
• xuhongqiang 备注：从STATUS windPendQPut(FAST Q_HEAD *pQHead, FAST int timeout)的实现中，我们可以看出，如果当前任务因为等待某一个信号量而被放置到该信号量的等待队列中去时，只是设置该任务的WIND_PEND位，如果其再被要求等待一段时间timeout的话，也只设置该任务的WIND_DELAY位，并放置到延时队列中去。特别需要指出的是其WIND_READY位并没有被清除，这意味着，当将一个任务从等待队列中移除时，只需要查看该任务的WIND_READY位，就可以确定该任务在放入到等待队列之前是否处于就绪状态，如果处于就绪状态就放置到就绪队列中。windLib库中操作等待队列的例程，均利用到了这一技巧，windPendQPut()我这里就不粘贴了，节省篇幅。 ---------------------------------------------------- 笔者您好，这个位置我不理解，当前任务被放进等待队列之前，除了是ready态，还能是什么状态?
• xuhongqiang 那么这种情况下，用户任务就可以不经过操作系统直接操作计算机资源，也就是说操作系统作为一个资源管理着没有记录到资源的使用，这是具有巨大的安全隐患的。难道说RTOS是用安全性换了实时性吗？ ---------- 这个问题是值得考虑的，我认为单态操作系统就是对安全性的放弃，追求实时性。笔者在写文章的时候，VxWorks应该还不支持动态加载？
• xuhongqiang 站点不能注册账号了，收不到邮箱验证码
• prtos, info Thanks♪(･ω･)ﾉ, PRTOS已经开源https://github.com/prtos-project/prtos-hypervisor，欢迎体验并提意见O(∩_∩)O~
• dingdang 大佬，看了一篇受益匪浅啊
• prtos, info 我明白了，是更新下文档git clone链接。 已经更新。
• prtos, info 这个我没有专门设置，你用git clone https://github.com/prtos-project/prtos-hypervisor.git 不能下载代码吗？
• 明贵 git clone git@github.com:prtos-project/prtos-hypervisor.git 是否改成https？git@需要在项目里面添加ssh key的，https 不需要账户的
• prtos, info test
• wheatfox 好！
• prtos, info 我没有遇到过这个问题，如果你采用跟我相同的host os，应该不会遇到这个问题。
• prtos, info vxworks cert是VxWorks 5.5的精简版，通过安全认证后，作为一个Guest OS运行在vxworks653的一个分区之上。
• silenceway 航空领域不一定都是用的vxworks 653 也有用vxworks cert的啊
• prtos, info 请参考http://www.prtos.org/prtos_hypervisor_x86_user_guide/ 体验PRTOS Hypervisor^_^
• prtos, info 开源，我的想法是先写一本 Hypervisor设计与实现方面的书，主要介绍PRTOS Hypervisor的设计与实现，然后再把配套的软件开源。这样可以让对这一块感兴趣的同学，有一个入门的途径。 理想的情况是形成一个开发社区，继续完成PRTOS的演化，比如完善软件设计、支持更多的平台，支持更多的Guest OS，支持商业化和安全认证等等方面。
• zzidd 大佬现在进展如何啊，很期待您的大作！
• prtos, info 谢谢鼓励，PRTOS的多核系统原型已经完成，支持分区Guest OS(Linux Kernel 3.4.4和RTOS uCOS-II)，计划今年年底和对应的图书一起开放出来。
• prtos, info 不客气，我会努力的，哈哈
• zzidd 感谢大佬的付出，国内在安全操作系统方面还很薄弱，需要更多的积累，向大佬致敬！！
• yan_36998 FDT_ERR_NOSPACE 这个出错如何解决呢，能否给说明一下，谢谢
• prtos, info VxWorks内核解读的是VxWorks5.5内核版本，是我在2012~2013年读研期间梳理的读书笔记。 之所以对VxWorks7的内核源码，我没有做深入的分析，主要是因为自己后来的研究方向和侧重点有所变动，主要精力不在这块^_^
• Jeremy 新的VxWorks7对该基础组件做了一些改变，摒弃了classClassId的设计，取而代之的是一个全局的classIdTable, 该全局classIdTable用于存储各组件的classId, 另外对于资源回收，RTP handle管理在该组件中被加入
• prtos, info 请留意出错提示，已经显示出错原因。
• 崩玉 你好，我在配置不同kernel的DOMU时，倒数第二步报错，这是什么原因，如何解决呢？感谢！ => fdt set /chosen/domU1/module@1 compatible "multiboot,ramdisk" "multiboot,module" libfdt fdt_setprop(): FDT_ERR_NOSPACE => fdt set /chosen/domU1/module@1 reg => booti 0x49000000 - 0x44000000 Bad Linux ARM64 Image magic!
• prtos, info Hi Simon，非常感谢你给出的WA，It works。我已经将你提供的WA更新到doc中O(∩_∩)O~
• prtos, info 不客气O(∩_∩)O~
• simon amba设备加载失败而导致Kernel panic： 禁用 ARM PL061 Advanced Microcontroller Bus Architecture dtc -I dtb -O dts virt-gicv3.dtb > virt-gicv3.dts sed 's/compatible = "arm,pl061.*/status = "disabled";/g' virt-gicv3.dts > virt-gicv3-edited.dts dtc -I dts -O dtb virt-gicv3-edited.dts > virt-gicv3.dtb
• prtos, info 非常感谢你的关注，我的初衷是开源PRTOS，并写一本介绍PRTOS设计与实践的书，让更多读者理解并运用好嵌入式Hypervisor的实现技术，嵌入式Hypervisor并不是在云端之上可望而不及，而是可以具体实现并能发挥重要经济价值的产品，优雅而精致。 前几年，因为工作重心不在这一领域，所以没有花太多的精力在这上面。今年计划着手付诸实施，同时也是为了实现自己最初的梦想。
• ilikerome 大佬是打算把 PRTOS 商业化，还是开源，还是只是个人研究啊，很多年之前看过你新浪~
• prtos, info 你说的没有问题,T3会被阻塞。如果此时只有T1和T3两个任务的话，T1会被恢复运行。T1运行完毕后，释放信号量，唤醒T1运行。 问题是低优先级的T1通常会被中等优先级的任务所抢占。例如此时的T2，这将会使T3无法释放T1需要的资源， 优先级翻转发生在T3和T2之间，这才是关键所在。
• prtos, info 1.如果具有MMU硬件的CPU不启用MMU，或者CPU没有MMU模块，这时OS访问的地址就是真实的物理地址； 2.如果具有MMU硬件的CPU启用MMU，对于RTOS来说（比如这里的VxWorks），物理地址和虚拟地址（即MMU映射后的地址）是1:1对应的平板内存。 所以，OS所在的地址空间，需要具体平台具体分析。 “实地址空间”指的是不管开始MMU与否，RTOS均运行在CPU的最高特权级，任务切换不会涉及到地址空间的切换，因为所有任务共享RTOS所具有的全局地址空间。 Anyway，“实时地址空间”确实会让人费解，已经修改为“实地址空间” ^_^
• prtos, info O(∩_∩)O~
• Luke "同时wind内核采取单一实时地址空间，任务切换开销非常低" “实时地址空间”？ 地址空间只能是1：1的Map 或者不是。 内核的话 其他操作系统也有单一的地址空间， 没有所谓的实时地址空间， 应该是实地址模式？
• Luke “当T1抢占T3通过获取相同的信号量来竞争这些资源的时候，T3将会被阻塞。如果我们能够保证T1阻塞的时间不会长于T3正在执行后释放这些资源的时间，情况不会发生特别严重，毕竟T1占用的这个资源是不可抢占的。” T1将会被阻塞， 因为T3已经拿到信号量了
• Jason 向大佬致敬！感谢分享！
• prtos, info 不客气，有啥问题，欢迎留言^_^
• 123 感谢作者的好文！ 非常感谢！
• prtos, info 最近工作比较忙，刚看到留言。有疑问的话，可以随时给我留言，或者发邮件到cwsun@prtos.org
• 嵌入式菜鸟 您好，最近在学习Vxworks操作系统的任务调度和中断处理等机制，拜读了大神的文章，有种醍醐灌顶的感觉。博主有联系方式么，有几个问题想咨询一下。
• prtos, info test
• prtos, info comment works
• prtos, info 对地址空间的保护，就涉及到CPU内核态和用户态的切换，进而是内核栈和用户栈的切换，比如分区上下文(涉及到通用寄存器、特权寄存器、MMU/MPU相关的寄存器、中断相关寄存器)的保护和恢复、以及Cache的刷新，这部分的开销是比较大的。
• prtos, info \(^o^)/~，最近工作太忙，暂时抽不出时间折腾，你有啥功能上的建议可以给我留言，我后续更新系统时作为一个参考。
• cohan 对博主的PRTOS很期待啊！
• cohan "现有的隔离和保护手段主要是借助于MMU和MPU对地址空间进行保护，存在保护力度大、资源消耗多、性能影响大等缺陷" 通过MMU和MPU进行内存保护主要是通过硬件单元实现的，软件只需在上下文切换时设置几个寄存器就行了，会导致“资源消耗多、性能影响大”的情况吗？没理解，还望赐教。
• prtos, info 嗯，是的。
• lijie 章节 1.1， “随着嵌入式CPU性能的提供”，这里的“提供”是笔误吧，应该是“提高”之类的。
• prtos, info 最近工作比较忙,你有啥问题可以给我留言，或者给我发邮件cwsun@prtos.com,技术方面大家可以互相交流O(∩_∩)O~
• YongYuan 站长您好！拜读您的文章，感觉您非常牛！您还做VXWORKS培训么？我想自费和您学习~ 可以留个联系方式么？我的wechat：四四9086497
• info 不好意思，无意之中删除了你的回复，不客气~
• prtos, info 第一个问题：这个理解不准确，比如Linux和vxWorks都支持POSIX接口，接口肯定是一致的。Linux和VxWorks最大的不同，Linux内核提供的服务接口是以系统调用的形式提供，涉及到特权态的转换；VxWorks由于所有任务运行在特权态下， 此时的“系统调用接口”，其实就是函数调用； 第二个问题：这个问题是RTOS出现的1980年代这个时间阶段决定的，当时的嵌入式处理器没有现在这么复杂，只有一种运行模式，因此侧重功能和性能，安全性完全寄托在开发者的操守。 但是2000年后，嵌入式CPU功能越发复杂，当前主流的RTOS，均会利用CPU的用户态和特权态，比如VxWorks6.x提出的RTP，以及VxWorks653，VxWorks MILS等分区系统的设计。 以及本网站侧重的PRTOS系统。
• yvonneason 感觉大致理解您的意思。你的意思是，无论是宏内核还是微内核，os都屏蔽了底层CPU差异，为用户的应用开发提供了接口；但是宏内核例如Linux，利用了cpu提供的特权机制，核心任务和用户任务使用的接口不一样；微内核不区分核心态和用户态，使用同样的接口，即函数调用的形式。我这样的理解是对的吗？那我还有一个问题，RTOS只运行在cpu的特权模式下，理论上讲用户任务和核心任务都可以访问到所有的cpu指令和内存空间。那么这种情况下，用户任务就可以不经过操作系统直接操作计算机资源，也就是说操作系统作为一个资源管理着没有记录到资源的使用，这是具有巨大的安全隐患的。难道说RTOS是用安全性换了实时性吗？
• prtos, info 问题1：统一的接口，是指OS屏蔽了底层CPU的差异，为用户的应用开发提供了一致的接口。比如不管是ARM平台、还是X86平台，wind内核创建任务始终是taskSpawn()接口，不会因为平台不同而差异，这是对同一个RTOS而言。传统意义上的RTOS(当然包括采用Wind的vxworks)只运行在CPU的特权模式下，所以相对于Linux的系统调用服务接口，RTOS下均以函数调用的形式提供。 问题2：正因为每一个款RTOS都有各自的接口，比如Wind内核和ucos均有自己各自的接口，为了减低应用在不同RTOS的移植难度，因此有了POSIX接口。