如何将共享地址空间进程模型扩展至设备与服务

首先，关于这个功能是否在REDHAWK的官方路线图中：目前我了解到的REDHAWK版本里，官方并没有将"让ComponentHost直接加载设备类型的SharedLibrary"作为核心路线图项。REDHAWK的设计中，设备通常是由DeviceManager负责管理和加载的，而ComponentHost的定位是专门处理通用组件（Components）的加载与运行。不过，如果你有明确的业务需求，完全可以通过提交Feature Request到REDHAWK的社区代码仓库来推动这个功能的官方支持。

接下来是针对这个扩展的实现建议，分几个关键步骤来推进：

1. 修改ComponentHost源码以支持设备加载 #

ComponentHost当前的逻辑只识别组件的make_component入口函数，你需要扩展它的能力：

• 添加设备入口函数支持：在ComponentHost的库加载逻辑中，新增对make_device这类设备专属入口函数的检测。当加载的SharedLibrary是设备类型时，调用make_device而非make_component。
• 适配设备构造参数：设备构造需要的Device Manager IOR等参数，你可以通过两种方式传递：
  • 修改ComponentHost的启动参数，允许用户传入Device Manager的IOR地址，在加载设备时将该参数传递给make_device函数；
  • 让ComponentHost自动发现并连接到本地或指定的Device Manager，动态获取IOR等必要参数。
• 调整生命周期管理：设备的生命周期（注册、初始化、配置、销毁）和普通组件不同，需要在ComponentHost中添加对应逻辑，比如调用设备的registerDevice方法向DeviceManager注册，处理设备特有的配置属性等。

2. 调整设备代码生成模板 #

你现在生成的设备代码还是保留了main函数，需要修改代码生成器的模板：

• 当选择生成SharedLibrary类型的设备时，自动生成make_device函数替代main函数。这个函数需要接收Device Manager IOR等必要参数，实例化设备对象并返回给ComponentHost。
• 调整设备构造函数的参数列表，确保它能接收ComponentHost传递过来的参数，或者从配置中读取所需的初始化信息。

3. 测试与兼容性验证 #

• 先编译修改后的ComponentHost，确保它能正确识别并加载设备SharedLibrary；
• 生成调整后的设备库，用修改后的ComponentHost启动，验证设备是否能成功注册到DeviceManager，并且正常处理数据或控制请求；
• 注意兼容性：因为你修改了核心组件，需要确保原有ComponentHost加载普通组件的功能不受影响，同时考虑不同REDHAWK版本的适配问题。

最后，如果你打算长期维护这个功能，建议将修改后的代码提交到REDHAWK社区，参与社区讨论，这样有可能被纳入官方版本，也能获得其他开发者的反馈和支持。

内容的提问来源于stack exchange，提问作者rodrigo455