丹阳火车站片区规划潍坊网站设计

丹阳火车站片区规划,潍坊网站设计,谢岗镇网站建设,黄山网站建设公司5.1 RTDM 框架 5.1.1. RTDM的诞生背景与核心目标 自所谓的双内核硬实时 Linux 扩展#xff08;如 RTLinux、 RTAI#xff09;引入以来#xff0c;已经开发了大量驱动程序。但是存在接口碎片化#xff0c;平台移植成本高的问题。尽管许多这些驱动程序针对相似的硬件#xf…5.1 RTDM 框架5.1.1. RTDM的诞生背景与核心目标自所谓的双内核硬实时 Linux 扩展如 RTLinux、 RTAI引入以来已经开发了大量驱动程序。但是存在接口碎片化平台移植成本高的问题。尽管许多这些驱动程序针对相似的硬件但大多数驱动程序定义了私有API应用层代码与驱动强耦合更换硬件需重写业务逻辑。由于不存在通用 API同一硬件如SJA1000 CAN卡需为Xenomai、RTAI分别开发驱动平台移植成本高。Real-Time Driver ModelRTDM 实时驱动模型旨在统一实时设备驱动程序和使用它们的应用程序的开发接口。RTDMReal-Time Driver Model是Xenomai的一部分用于支持实时驱动的开放与运行。它的目的就是让开发者在实时内核(Cobalt core)上编写驱动程序时有一个统一的接口模型而不是直接依赖Linux的内核驱动框架例如字符设备、块设备和网络设备。这保证了驱动的实时性避免因为Linux内核的调度或锁机制而引入不可预测的延迟。独立的驱动模型separate driver modelRTDM 提供了一套与Linux内核驱动模型分离的API例如 rtdm_driver, rtdm_device驱动通过 RTDM 框架注册到 Xenomai 的实时核心中而不是注册到 Linux 的 VFS 或设备模型。应用程序可以通过独立的注册和调用separate registration and invocation注册registration驱动作者需要用 RTDM 的 APIrtdm_dev_register()来注册设备调用 (invocation)用户空间程序通过 RTDM 设备文件调用对应的实时驱动。RTDM syscalls (/dev/rtdm/…) 来调用这些驱动绕过 Linux 的常规路径。带外感知 Aware 驱动程序Xenomai RTDM 驱动的历史和现状问题很多驱动在 Linux 内核里已经存在 (如 GPIOCAN 串口 SPI 等)但这些驱动没有实时保证。Xenomai 社区要么 fork Linux 驱动 然后改造成 RTDM 驱动要么单独开放专用的 RTDM 驱动。这些驱动的维护要和 Linux 主线分离 长期靠 Xenomai 社区或厂商单独维护。针对设备RTDM 实现了统一设备抽象层定义两类标准化设备模型协议设备/命名设备覆盖90%实时场景。协议设备支持面向消息的即通过调用socket()进行创建设备。命名设备支持可用open()函数实例化包括流式设备或控制类设备。为同类硬件如UART、CAN定义Device Profiles接口规范实现应用与硬件解耦。针对设备驱动RTDM 实现了一个跨平台的 RTOS 服务抽象层封装了任务调度、同步原语等共性服务驱动仅依赖 RTDM API。RTOS 服务抽象层允许为任何实现 RTDM 的 Linux 平台开发可移植的设备驱动程序。RTDM不仅能用于编写设备驱动还可以用于扩展RTnet协议栈RTIPC功能等是对 Cobalt 内核的有效补充它让 Cobalt 内核更加专注提供核心功能更加简洁。5.1.2 RTDM 层次结构1. RTDM 的角色应用程序一般总是通过硬件设备驱动程序来访问硬件设备。RTDM在应用程序和驱动程序之间充当了一个调解者的角色。在 RTDM 和应用程序之间RTDM 提供 high-level 上层API遵循 POSIX 套接字和 I/O 模型即用户层APIRTDM skin。在 Xenomai3 中RTDM skin是POSIX skin的别名。通过xeno-config --skin获取编译与链接参数时选项--skinrtdm与--skinposix严格等效。在 RTDM 和驱动程序之间RTDM 提供 low-level 底层API旨在提供一个用于构建可移植驱动程序的小型 RTOS 抽象层。图中的Wrapper Library包装库和Hardware Abstraction LayerHAL硬件抽象层并不在 RTDM 的范围内。它们是可以根据需要添加的可选间接层以实现进一步的抽象。引入Wrapper Library包装库可以简化相同类别的设备对上层 RTDM API 的使用。推荐使用 HAL硬件抽象层可以重用多个驱动程序的公共代码段例如附加在不同低级通信适配器驱动程序上的协议堆栈。Xenomai的双核系统的关键就是保证head(实时域Out-of-Band)和root(非实时域, In-Band)的连续处理驱动也是这样。比如之前提到的RTDM的锁体系对 Linux-Devetail 硬自旋锁的封装链条从最底层的硬自旋锁hard_spinlock_t- 管线自旋锁pipeline_spinlock_t- RTDM层的rtdm_lock_t,保证在不同上下文IRQ/任务/管线访问共享资源时的原子性和安全性。驱动的处理方式双域驱动涉及RTDM 驱动把核心硬件操作放在 head (OOB)控制、配置、调度等操作放在 root (非实时域)连续处理IRQ 先到 head 处理保证低延迟响应再同步到 root, 保证 Linux 内核可以看到事件2. RTDM 堆叠RTDM 支持并鼓励驱动程序堆叠如下图所示其中堆叠了 2 层 RTDM。但驱动程序开发人员仍然可以自由定义适当的其他驱动程序层。5.1.3 RTDM 统一设备抽象层1. 设备模型以 LInux 的方式看待设备可区分为 3 种基本设备类型字符模块, 块模块, 或者一个网络模块.RTDM 支持两种不同类型的设备。它们是根据目前实时 Linux 驱动程序的特性选择的。RTDM 不包含实时块设备模型甚至不包含文件系统模型。协议设备 所有面向消息的设备都属于这一组类似于 Linux 中的网络模块。协议设备使用两个标识符进行注册即协议族和套接字类型。它们根据 POSIX 套接字模型进行寻址即通过调用 socket()进行创建通过 close()进行销毁。至少它们必须提供对发送和接收消息的支持sendmsg()和 recvmsg()send()/sendto()和 recv()/recvfrom()在内部映射到这些函数。此外协议设备的驱动程序可以通过 ioctl()处理发出的请求。ioctl()接口还用于将剩余的套接字调用如 bind()、connect()、listen()、accept()、shutdown()、getsockopt()、setsockopt()、getsockname()和 getpeername()传递给驱动程序。选择这种映射是为了避免在 RTDM 层中为不常使用的函数创建大量入口点。以bind()的代码实现为例其内部调用了ioctl()接口。COBALT_IMPL(int, bind, (int fd, const struct sockaddr *my_addr, socklen_t addrlen)) { struct _rtdm_setsockaddr_args args { my_addr, addrlen }; int ret; ret do_ioctl(fd, _RTIOC_BIND, args); if (ret ! -EADV ret ! -ENOSYS) return set_errno(ret); return __STD(bind(fd, my_addr, addrlen)); }命名设备 这些设备在实时子系统下以唯一的清晰文本名称注册然后可以通过 open()函数实例化。类似于 Linux 中的字符设备。RTDM 不维护特定的命名层次结构或文件系统。基本上驱动程序在选择设备名称方面是自由的但在设备配置文件中为常见类指定了常规的命名方案。命名设备可以进一步细分为:流式设备支持流导向 I/Oread()/write()访问的设备例如 UART 设备SPI 设备。功能设备仅通过 ioctl()接口提供功能的设备。包括所有不符合消息和流导向模型的设备。2. 设备规范Device Profilesstruct rtdm_device和struct rtdm_driver结构体是对设备和驱动的抽象统一的结构体可用简化设备驱动程序的实现并提高其可移植性。struct rtdm_device和struct rtdm_driver结构体成员的定义和取值与设备自身特点息息相关。针对不同的硬件设备类型RTDM 为结构体成员变量和成员函数预先定义了取值规范及衍生出来的必要的数据结构和常量统称为设备配置规范Device Profiles。设备特性device_flags设备类型/** 如果设置则应用程序只能请求该设备的一个实例。 */ #define RTDM_EXCLUSIVE 0x0001 /** * 使用在 rtdm_device 描述中提供的固定 minor 进行注册。 * 如果此标志不存在则 RTDM 核心会根据注册顺序为由驱动程序管理的设备分配 minor 号。 */ #define RTDM_FIXED_MINOR 0x0002 /** 如果设置则设备通过命名名称进行访问。 */ #define RTDM_NAMED_DEVICE 0x0010 /** 如果设置则设备通过协议 ID 和套接字类型组合进行访问。 */ #define RTDM_PROTOCOL_DEVICE 0x0020 /** 选择设备类型的掩码。 */ #define RTDM_DEVICE_TYPE_MASK 0x00F0 /** 标志表示 RTDM 的安全变体尚未支持 */ #define RTDM_SECURE_DEVICE 0x80000000profile_info宏定义RTDM_PROFILE_INFO用于初始化profile_info信息。__name: 类名称自定义。__id: 类主标识号用于唯一标识该类。#define RTDM_CLASS_PARPORT 1 #define RTDM_CLASS_SERIAL 2 #define RTDM_CLASS_CAN 3 #define RTDM_CLASS_NETWORK 4 #define RTDM_CLASS_RTMAC 5 #define RTDM_CLASS_TESTING 6 #define RTDM_CLASS_RTIPC 7 #define RTDM_CLASS_COBALT 8 #define RTDM_CLASS_UDD 9 #define RTDM_CLASS_MEMORY 10 #define RTDM_CLASS_GPIO 11 #define RTDM_CLASS_SPI 12 #define RTDM_CLASS_PWM 13 #define RTDM_CLASS_MISC 223 #define RTDM_CLASS_EXPERIMENTAL 224 #define RTDM_CLASS_MAX 255__subid: 类次标识号用于进一步细分该类一般由各驱动自行定义。__version: 配置版本号用于表示该类配置的版本一般由各驱动自行定义。protocol_family 协议族PF_CANPF_INETPF_PACKETPF_RTIPCsocket_type 套接字类型SOCK_DGRAMSOCK_RAWSOCK_STREAM支持的操作struct rtdm_fd_ops中定义了所有可能的操作 驱动程序按设备需求按需选择实现哪些操作。由于在实时上下文中与非实时上下文相比必须使用不同的同步机制和资源分配策略因此明确区分服务调用上下文至关重要。为了让驱动程序决定如何处理不同的上下文可以为每个入口类型安装单独的处理程序。如果处理程序是上下文无关的则也可以为两个入口点注册相同的处理程序。opensocketcloseioctl_rtioctl_nrtread_rtread_nrtwrite_rtwrite_nrtrecvmsg_rtrecvmsg_nrtsendmsg_rtsendmsg_nrtselectmmapget_unmapped_area类型和常量为描述设备而引入的结构IOCTL使用的选项或其他数据类型以及在RTDM上下文中使用的任何常量。设备必须提供的 IOCTL 选项。通用的IOCTL选项定义在include/rtdm/uapi/rtdm.h中包括_RTIOC_GETSOCKOPT_RTIOC_SETSOCKOPT_RTIOC_BIND _RTIOC_CONNECT等。串口相关的IOCTL选项定义在include/rtdm/uapi/serial.h包括RTSER_RTIOC_GET_CONFIGRTSER_RTIOC_SET_CONFIGRTSER_RTIOC_GET_CONTROL等。CAN相关的IOCTL选项定义在include/rtdm/uapi/can.h包括RTCAN_RTIOC_TAKE_TIMESTAMPRTCAN_RTIOC_RCV_TIMEOUTRTCAN_RTIOC_SND_TIMEOUT等。GPIO相关的IOCTL选项定义在include/rtdm/uapi/gpio.h包括GPIO_RTIOC_DIR_OUTGPIO_RTIOC_DIR_INGPIO_RTIOC_IRQEN等。未其它设备及驱动定义的IOCTL选项不再一一列举。其它数据类型和宏定义等一般定义在include/rtdm/uapi/rtdm.hinclude/rtdm/uapi/serial.hinclude/rtdm/uapi/can.h等头文件中。3. 设备注册和调用通过将struct rtdm_device *dev设备描述传递给 rtdm_dev_register()来注册 RTDM 设备。注册命名设备static struct rtdm_driver foo_driver { .profile_info RTDM_PROFILE_INFO(foo, RTDM_CLASS_EXPERIMENTAL, RTDM_SUBCLASS_FOO, 42), .device_flags RTDM_NAMED_DEVICE|RTDM_EXCLUSIVE, .device_count 2, .context_size sizeof(struct foo_context), .ops { .open foo_open, .ioctl_rt foo_ioctl_rt, .ioctl_nrt foo_ioctl_nrt, .close foo_close, }, }; static struct rtdm_device foo_devices[2] { [ 0 ... 1 ] { .driver foo_driver, .label foo%d, }, }; MODULE_VERSION(1.0.0); MODULE_DESCRIPTION(Ultra-void IV board driver); MODULE_AUTHORWhoever); foo_devices[0].device_data some_driver_data0; ret rtdm_dev_register(foo_devices[0]); ... foo_devices[1].device_data some_driver_data1; ret rtdm_dev_register(foo_devices[1]);这段代码演示了如何基于基于RTDMReal-Time Device Model框架定义和注册一个命名设备的实时设备驱动程序。首先定义了一个名为foo_driver的静态结构体用于描述驱动程序的基本信息和操作接口。具体来说profile_info字段包含了驱动程序的配置信息如驱动名称、类别、子类别和版本号。device_flags字段设置了设备的标志这里表明设备是命名设备并且是独占的。device_count字段指定了将由该驱动程序控制的设备数量在这里为2。context_size字段定义了设备上下文的大小即每个设备的内存需求这里使用sizeof(struct foo_context)来获取foo_context结构体的大小。ops字段是一个指向结构体的指针该结构体定义了设备的操作函数如打开foo_open、实时IO控制foo_ioctl_rt、非实时IO控制foo_ioctl_nrt和关闭foo_close。接下来定义了一个包含两个设备的静态数组foo_devices每个设备都关联到上面定义的foo_driver驱动程序并且其标签被设置为foo%d这里的%d是一个占位符实际使用时会被设备的具体编号0或1替换。最后将两个设备的数据指针分别指向不同的驱动数据结构some_driver_data0和some_driver_data1然后通过rtdm_dev_register函数注册这两个设备。应用程序可以通过以下两种方式打开设备。推荐的使用方式Xenomai 应用程序使用实际的设备节点路径来打开RTDM设备。例如fdopen(/dev/rtdm/devname,...);这种方法不仅符合最新的命名规范还能避免潜在的兼容性问题和警告信息。在Xenomai 2.x中 RTDM 设备节点使用的是旧的命名规则到了 Xenomai 3RTDM 框架改造后设备节点的路径和命名方式也有了变化。这意味着老应用程序如果直接移植到Xenomai 3上可能会找不到原有的设备节点路径导致open()失败。XENO_OPT_RTDM_COMPAT_DEVNODE是一个布尔类型的配置选项位于drivers菜单下。其默认值为y表示启用。该选项允许应用程序在打开RTDM设备时使用旧的命名方案这样就保证了向后兼容减少应用移植工作量。fd open(devname, ...);fd open(/dev/devname, ...);当应用程序使用上述旧命名方案打开RTDM设备时如果内核配置中启用XENO_OPT_DEBUG_LEGACYXenomai 会在内核日志中发出警告信息。注册协议设备static struct rtdm_driver foo_driver { .profile_info RTDM_PROFILE_INFO(foo, RTDM_CLASS_EXPERIMENTAL, RTDM_SUBCLASS_FOO, 1), .device_flags RTDM_PROTOCOL_DEVICE, .device_count 1, .context_size sizeof(struct foo_context), .protocol_family PF_FOO, .socket_type SOCK_DGRAM, .ops { .socket foo_socket, .close foo_close, .recvmsg_rt foo_recvmsg, .sendmsg_rt foo_sendmsg, .ioctl_rt foo_ioctl, .ioctl_nrt foo_ioctl, .read_rt foo_read, .write_rt foo_write, .select foo_select, }, }; static struct rtdm_device foo_device { .driver foo_driver, .label foo, .device_data some_driver_data, }; ret rtdm_dev_register(foo_device); ... MODULE_VERSION(1.0.0); MODULE_DESCRIPTION(Unexpected protocol driver); MODULE_AUTHORWhoever);这段代码演示了如何基于基于RTDMReal-Time Device Model框架定义和注册一个协议设备的实时设备驱动程序。首先定义了一个名为foo_driver的静态结构体用于描述驱动程序的基本信息和操作接口。具体来说profile_info: 描述了驱动程序的基本信息包括驱动名称foo、类别实验性的RTDM_CLASS_EXPERIMENTAL、子类别RTDM_SUBCLASS_FOO和版本号1。device_flags: 设备标志表示设备是一个协议设备RTDM_PROTOCOL_DEVICE。device_count: 指定该驱动程序控制的设备数量为1。context_size: 设备上下文的大小使用sizeof(struct foo_context)来确定。protocol_family: 协议族这里为PF_FOO表示使用自定义的协议族。socket_type: 套接字类型这里是SOCK_DGRAM表示数据报套接字。ops: 定义了设备的操作函数包括创建套接字foo_socket、关闭设备foo_close、实时接收消息foo_recvmsg、实时发送消息foo_sendmsg、实时IO控制foo_ioctl_rt、非实时IO控制foo_ioctl_nrt、实时读取foo_read、实时写入foo_write和选择foo_select。接下来定义了一个foo_device设备关联到foo_driver驱动程序并且其标签被设置为foo。其中device_data代表设备数据指针指向some_driver_data结构体。最后调用rtdm_dev_register(foo_device)将设备注册到RTDM框架中。在应用程序中可直接调用socket相关接口使用 RTDM 设备。例如初始化一个 socket 实例txsock socket(PF_CAN, SOCK_RAW, 0)具体实例可以参考demo/posix/cobalt/can-rtt.c。5.1.4 RTDM RTOS 服务抽象层为了提高驱动程序的可移植性RTDM 提供了一个与底层系统无关的通用 API涵盖基本的 RTOS 服务。该 API 旨在仅提供典型实时驱动程序所需的最小服务集。这有助于保持 RTDM 层的小巧性并且还提高了其在其他实时 Linux 变体上的可移植性。以下服务组可用驱动内联服务提供驱动之间可相互调用的接口。时钟服务提供接口用于获取系统时钟或单调时钟都是以 64 位值表示单位为纳秒。任务服务此组函数允许驱动程序创建自己的实时任务挂起用户和驱动程序任务的执行或操作它们的特性优先级和周期性。定时器服务提供定时器服务。同步服务RTDM 提供各种基本同步服务。首先自旋锁可用于保护小的临界路径无论它们是否位于中断处理程序中或在非实时上下文中运行。经典的互斥锁和信号量也可用于同步实时任务。同时支持事件机制可作为信号量的替代方案。中断管理服务对于大多数硬件驱动程序中断是必不可少的服务。可以使用 RTDM 注册实时中断线的处理程序并且可以明确启用和禁用这些中断线。非实时信号服务为了将事件从实时域传播到非实时域可以从 RTDM 层请求特殊的信号服务。从任何上下文触发此类信号都是安全的。一旦没有更多时间关键任务待处理注册的处理程序将在非实时上下文中执行。实用工具服务此组服务包括实时内存分配、对用户空间内存区域的安全访问、实时安全的内核控制台输出以及检查当前上下文是否为实时任务等待。在后续的章节会详细介绍上述各种服务。5.1.5 在 Xenomai3 中集成的RTDM驱动xenomai-v3.2.4/kernel/drivers/目录下列出了 Xenomai3 支持的驱动程序以下是这些子目录及其包含的驱动程序的简要介绍autotune包含自动调优驱动程序用于优化实时系统的性能和配置。serial包含串行通信驱动程序支持 UART通用异步收发传输器等串行接口设备。can包含 CANController Area Network总线驱动程序用于支持 CAN 网络接口设备。net包含网络驱动程序支持以太网控制器等网络接口设备用于实时网络通信。analogy包含模拟输入和输出驱动程序支持 ADC模数转换器和 DAC数模转换器等模拟接口设备。ipc包含进程间通信IPC驱动程序支持实时环境下的消息传递、共享内存等通信机制。udd包含用户设备驱动UDD驱动程序允许用户空间程序通过 RTDM 接口与设备进行交互。gpio包含通用输入输出GPIO驱动程序支持硬件上的输入输出引脚。gpiopwm包含基于 GPIO 的 PWM脉宽调制驱动程序利用 GPIO 引脚实现 PWM 功能。spi包含 SPI串行外设接口总线驱动程序用于支持 SPI 接口设备。分别重点介绍串行设备和RTnet它们分别是命名设备和协议设备的典型代表。1. 串行设备通过 read/write 提供对串行设备的访问是一种命名设备。定义了 IOCTL 以操作输出状态线、获取输入线、等待设备事件以及配置串行设备的线路特性、超时和事件。已经支持的串行设备驱动包括16550A UARTMPC52xx UARTIMX UART以16550A UART驱动为例static struct rtdm_driver uart16550A_driver { .profile_info RTDM_PROFILE_INFO(uart16550A, RTDM_CLASS_SERIAL, RTDM_SUBCLASS_16550A, RTSER_PROFILE_VER), .device_flags RTDM_NAMED_DEVICE | RTDM_EXCLUSIVE, .device_count MAX_DEVICES, .context_size sizeof(struct rt_16550_context), .ops { .open rt_16550_open, .close rt_16550_close, .ioctl_rt rt_16550_ioctl, .ioctl_nrt rt_16550_ioctl, .read_rt rt_16550_read, .write_rt rt_16550_write, }, }; int __init rt_16550_init(void) { struct rtdm_device *dev; ...snips... dev kmalloc(sizeof(struct rtdm_device) RTDM_MAX_DEVNAME_LEN, GFP_KERNEL); err -ENOMEM; if (!dev) goto cleanup_out; dev-driver uart16550A_driver; dev-label rtser%d; ...snips... err rtdm_dev_register(dev); ...snips... }上述代码定义了一个名为 uart16550A_driver 的 RTDM 驱动程序用于支持 16550A UART 串行通信设备。该驱动程序的配置信息通过 RTDM_PROFILE_INFO 宏初始化设置了类名称、主标识号、次标识号和版本号。驱动的设备标志包括 RTDM_NAMED_DEVICE 和 RTDM_EXCLUSIVE表示设备可以通过名称访问且为独占设备。驱动的最大设备数量为 MAX_DEVICES上下文大小为 sizeof(struct rt_16550_context)。驱动程序的操作函数包括 open、close、ioctl_rt、ioctl_nrt、read_rt 和 write_rt分别用于设备的打开、关闭、控制、读取和写入操作。在 rt_16550_init 函数中初始化过程中动态分配了一个 rtdm_device 结构体并将其与 uart16550A_driver 关联。设备的标签设置为 “rtser%d”然后通过 rtdm_dev_register 函数注册设备。如果设备注册失败会进行相应的错误处理和清理操作。2. RTnet 实时网络RTnet 实时网络分为 2 大部分实时网络协议堆栈 和 实时网络设备。实时网络协议堆栈定义在kernel/drivers/net/stack/目录由不同的 RTDM 设备组成及相关的数据结构和IOCTL定义等组成。当前支持的协议栈包括协议设备实时 UDP协议设备实时 TCP协议设备实时 Packet以 UDP 实时协议栈kernel/drivers/net/stack/ipv4/udp为例static struct rtdm_driver udp_driver { .profile_info RTDM_PROFILE_INFO(udp, RTDM_CLASS_NETWORK, RTDM_SUBCLASS_RTNET, RTNET_RTDM_VER), .device_flags RTDM_PROTOCOL_DEVICE, .device_count 1, .context_size sizeof(struct rtsocket), .protocol_family PF_INET, .socket_type SOCK_DGRAM, /* default is UDP */ .ops { .socket rt_inet_socket, .close rt_udp_close, .ioctl_rt rt_udp_ioctl, .ioctl_nrt rt_udp_ioctl, .recvmsg_rt rt_udp_recvmsg, .sendmsg_rt rt_udp_sendmsg, .select rt_socket_select_bind, }, }; static struct rtdm_device udp_device { .driver udp_driver, .label udp, }; static int __init rt_udp_init(void) { ...snips... err rtdm_dev_register(udp_device); ...snips... }上述代码首先定义了一个名为udp_driver的 RTDMReal-Time Device Model驱动程序用于支持实时环境下的 UDP 网络通信。该驱动程序的配置信息通过RTDM_PROFILE_INFO宏初始化设置了类名称为udp主标识号为RTDM_CLASS_NETWORK次标识号为RTDM_SUBCLASS_RTNET版本号为RTNET_RTDM_VER。驱动的设备标志为 RTDM_PROTOCOL_DEVICE表示设备通过协议 ID 和套接字类型进行访问。设备数量为 1上下文大小为 sizeof(struct rtsocket)。驱动程序的操作函数包括socket: 使用 rt_inet_socket 创建套接字。close: 使用 rt_udp_close 关闭套接字。ioctl_rt 和 ioctl_nrt: 使用 rt_udp_ioctl 进行实时和非实时的控制操作。recvmsg_rt: 使用 rt_udp_recvmsg 接收数据报。sendmsg_rt: 使用 rt_udp_sendmsg 发送数据报。select: 使用 rt_socket_select_bind 进行选择操作。此外还定义了一个 rtdm_device 结构体 udp_device并将其与 udp_driver 关联设备标签设置为 “udp”。在 rt_udp_init 函数中初始化过程中注册了 udp_device使其在实时环境中可用。实时网络设备定义在kernel/drivers/net/drivers/目录。用struct rtnet_device结构体来定义实时网络设备由rt_register_rtnetdev向实时网络协议堆栈注册网络接口并调用 RTDM RTOS抽象层 完成相关驱动工作。当前支持的实时网络设备如下Intel e1000e1000eigbeepro100等Freescale fecmpc52xx_fecmpc8260_fcc_enetmpc8xx_enetmpc8xx_fec等RTL r81698139too等Cadence MACB/GEM等其它网口如loopbacktulipnatsemivia-rhineat91_ether等等。5.1.6 RTDM 驱动的设计哲学5.1.6.1 RTDM 的设计定位实时优先而非硬件发现RTDM 的设计目标是为实时驱动程序提供一个统一的接口模型而不是一个通用的硬件抽象层HAL。RTDM 关注的是驱动程序的实时性和可移植性而不是硬件发现和管理。