在RTOS中，将不那么重要的代码保留在RTOS之外以最小化代码大小只是一种惯例吗？
这不是一个惯例问题，也与“重要性”无关。RTOS供应商/作者很难确定嵌入式应用程序中什么是重要的。RTOS通常不是真正的“完整操作系统”，而只是一个确定性的实时线程或进程调度器，具有IPC，定时和同步服务。他们只做好一件事，其他一切都取决于应用程序开发人员。此外，大多数RTOS只不过是用于构建单个单片多线程应用程序的静态链接库，而不是可以动态加载、执行和终止进程的操作系统。因此，从这个意义上说，提供的任何shell都不是您建议的单独应用程序，而是一个单独的库组件，并且在运行时是一个单独的线程或任务。
此外，典型的嵌入式应用程序通常在具有严格内存限制的自定义硬件上运行，因此RTOS通常必须是最小的或可扩展的，以便它仅包含嵌入式应用程序所需的内容。其中“中间件”，如文件系统，网络，USB，命令shell等。它们通常由第三方库或附加组件提供，并作为线程而不是在内核中运行;因为同样是应用程序开发者确定什么任务是实时关键的并且必须抢占任何其它操作。因此，它也是关于有完整的调度控制。
shell不是Linux操作系统的一部分吗？
它不是Linux * 内核 * 的一部分（而且Linux不是RTOS）。大多数Linux发行版都包含一个shell，而Linux的本质是，某种形式的shell对于调试、配置和维护是必要的，或者至少是方便的。但是Linux很难与之相比;一个最小的“轻量级”发行版需要大约4 Mb的ROM和16 Mb的RAM来勉强 Boot ，而一个典型的RTOS内核需要< 4Kb的ROM和非常少的RAM。
为什么shell不应该像内存管理器等模块一样放在操作系统代码中？如果我把shell代码移到RTOS中，作为RTOS的一部分，像其他RTOS模块一样初始化和启动，会有什么问题吗？
目前还不清楚你所说的“在RTOS内部”是什么意思，在任何特定情况下你可以做什么将是特定于该产品的。在RTOS是静态库的情况下，没有内部或外部的RTOS，它都是一个应用程序。在RTOS * 内核 *（执行调度的部分）方面，这没有什么意义。
以上描述了一个典型的RTOS。产品在所包含的内容方面差异很大，但大多数都是高度可扩展的。例如FreeRTOS或uC/OS-II等产品只是调度内核，而eCOS、QNX和P2P Works在不同程度上是更完整的操作系统，包括文件系统、 shell 、网络组件，在某些情况下还有清晰的设备驱动程序架构，甚至在某些情况下还有POSIX API。