您的位置:首页 > 运维架构 > Linux

【原创】xenomai内核解析--xenomai与普通linux进程之间通讯XDDP(一)--实时端socket创建流程

wsg1100 2020-10-01 18:59 44 查看 https://www.cnblogs.com/wsg110

版权声明:本文为本文为博主原创文章,转载请注明出处。如有问题,欢迎指正。博客地址:https://www.cnblogs.com/wsg1100/

1.概述

上篇文章xenomai内核解析--实时IPC概述中介绍了RTIPC,从这篇文章开始开始深入xenomai内核,解析RTIPC的具体实现。

XDDP、IDDP和BUFP由于应用场景不一样,所以底层不一样,但也区别不大。XDDP用于xenomai任务与普通Linux任务通讯,提供两种方式,一种是每次读写作为一个数据报来操作,对应实时任务间的通讯方式IDDP;另一种为可以将多次读写的数据缓冲最后组成一个大的数据报发送,对应实时任务间的BUFP方式。所以解析了XDDP原理,那么IDDP和BUFP自然也就懂了,后面文章我也会简单说一下IDDP、XDDP。

需要先说明一下 XDDP几乎涉及了xenomai的所有关键组件,通过解析xenomai内核XDDP的实现源码,你会明白:

  • xenomai内核: XDDP的详细实现。
  • 实时设备驱动模型:RTDM是如何管理协议类设备的,应用是如何找到并使用具体的协议设备的(其实和Linux类似),如何为xenomai添加一个自定义协议设备等。
  • Linux端:字符类设备管理、虚拟文件系统VFS;
  • 通讯过程中的内存分配释放:实时内存堆-xnheap,详见xenomai内核解析--实时内存管理--xnheap
  • xenomai资源同步互斥机制:xnsynch
  • 如何跨域唤醒指定任务:ipipe虚拟中断xnpipe_wakeup_apc
  • ## 2.XDDP的使用注意事项

    上篇文章已经介绍了具体的使用方法,linux端通过

    read()、write()
    读写
    /dev/rtp<minor>
    /proc/xenomai/registry/rtipc/xddp/label
    来通讯,Xenomai端通过套接字
    recvfrom()或read()
    来接收数据,
    sendto()或write()
    来发送数据。其中需要注意的是:

    • XDDP 只能由xenomai应用(使用Libcobalt库编译)创建.
    • 由于端口号与Linux端次设备号绑定,所以必须两边都关闭释放了才能再次使用同一个端口(可见文末总框图)。

    下面我们就沿着这个流程到内核里面一探究竟,看看在内核里面,都创建了哪些数据结构,做了哪些事情。

    3.解析socket函数

    从调用socket()函数开始。对于xenomai实时程序,该函数不是直接就执行系统调用,而是由xenomai实时库libcobalt中实现,实时应用编译时会链接到该库。

    /*xenomai-3.x.x\lib\cobalt\rtdm.c*/
    COBALT_IMPL(int, socket, (int protocol_family, int socket_type, int protocol))
    {
    int s;
    s = XENOMAI_SYSCALL3(sc_cobalt_socket, protocol_family,
    socket_type, protocol);
    if (s < 0) {
    s = __STD(socket(protocol_family, socket_type, protocol));
    }
    return s;
    }

    从该函数可以看到,首先执行xenomai内核调用,如果xenomai系统调用返回负值,一种情况时产生了错误,另一种情况说明这些参数不是要实时内核提供服务的,接着才去调用标准库执行linux的系统调用。这就实现了同一接口也可以让linux提供服务。

    创建socket的时候有三个参数,一个是

    protocol_family
    表示地址族,在linux中,如下两种是比较熟悉的。

    #define AF_UNIX 1/* Unix domain sockets */
    #define AF_INET 2/* Internet IP Protocol */

    对于xenomai,

    protocol_family
    只有一种,如果自己为xenomai内核添加自定义的协议设备就可以通过该参数识别:

    /* Address family */
    #define AF_RTIPC		111
    
    /* Protocol family */
    #define PF_RTIPC		AF_RTIPC

    第二个参数是

    socket_type
    ,也即 Socket 的类型。类型是比较少的。

    第三个参数是

    protocol
    ,是协议。协议数目是比较多的,也就是说,多个协议会属于同一种类 型。

    常用的 Socket 类型有三种,分别是

    SOCK_STREAM
    SOCK_DGRAM
    SOCK_RAW

    enum sock_type {
    SOCK_STREAM	= 1,
    SOCK_DGRAM	= 2,
    SOCK_RAW	= 3,
    ......
    };

    SOCK_STREAM
    是面向数据流的,协议 IPPROTO_TCP属于这种类型。
    SOCK_DGRAM
    是面 向数据报的,协议IPPROTO_UDP 属于这种类型。如果在内核里面看的话,IPPROTO_ICMP 也属于这种类型。
    SOCK_RAW
    是原始的 IP 包,IPPROTO_IP 属于这种类型。

    对于

    socket_type
    ,在xenomai 中,通讯是在系统内部,统一为数据报即
    SOCK_DGRAM
    ,其余无效。xenomai提供的
    protocol
    如下几种:

    enum {
    /** Default protocol (IDDP) */
    IPCPROTO_IPC  = 0,
    IPCPROTO_XDDP = 1,
    IPCPROTO_BUFP = 3,
    IPCPROTO_MAX
    };

    其实xenomai提供的rtipc只作为实时进程间通讯,内部与linux socket一点关系都没有,从上就可以看出,仅是函数接口相同而已。

    这一节,我们重点看

    IPCPROTO_XDDP
    协议。实时系统调用
    sc_cobalt_socket
    对应内核代码如下。它会调用
    __rtdm_dev_socket()

    /*kernel\xenomai\posix\io.c*/
    COBALT_SYSCALL(socket, lostage,
    (int protocol_family, int socket_type, int protocol))
    {
    return __rtdm_dev_socket(protocol_family, socket_type, protocol);
    }
    /*kernel\xenomai\rtdm\core.c*/
    int __rtdm_dev_socket(int protocol_family, int socket_type,
    int protocol)
    {
    struct rtdm_dev_context *context;
    struct rtdm_device *dev;
    int ufd, ret;
    
    secondary_mode_only();
    
    dev = __rtdm_get_protodev(protocol_family, socket_type);
    ......
    
    ufd = __rtdm_anon_getfd("[rtdm-socket]", O_RDWR);
    ......
    ret = create_instance(ufd, dev, &context);
    ......
    if (dev->ops.socket) {
    ret = dev->ops.socket(&context->fd, protocol);
    ......
    }
    ......
    ret = rtdm_fd_register(&context->fd, ufd);
    ......
    
    return ufd;
    }

    secondary_mode_only()
    表示目前上下文必须是linux域,应为涉及到linux一些资源分配,如文件描述符。你可能会疑惑,我们创建调用socket函数的应用已经在实时线程里了,而且我们使用实时库libcobalt发起的系统调用,进内核后应该是haed域,而这里为什么还secondary_mode_only?解答这个问题请移步本博客其他文章xenomai内核解析--双核系统调用(一)小节的权限控制。

    先是根据

    protocol_family
    socket_type
    转换为
    xnkey_t
    来查找对应的rtdm_device.

    struct rtdm_device *__rtdm_get_protodev(int protocol_family, int socket_type)
    {
    struct rtdm_device *dev = NULL;
    struct xnid *xnid;
    xnkey_t id;
    secondary_mode_only();
    
    id = get_proto_id(protocol_family, socket_type);
    mutex_lock(&register_lock);
    
    xnid = xnid_fetch(&protocol_devices, id);
    if (xnid) {
    dev = container_of(xnid, struct rtdm_device, proto.id);
    __rtdm_get_device(dev);
    }
    mutex_unlock(&register_lock);
    
    return dev;
    }

    3.1 RTDM Protocol Devices

    id类型为longlong,高32位为

    protocol_family
    ,低32位为
    socket_type
    ,将它作为key在红黑树
    protocol_devices
    上找到对应的设备。

    static struct rb_root protocol_devices;

    protocol_devices
    是一个全局变量,其类型是struct rb_root,我们知道xenomai 实时驱动模型(RTDM)将所有实时设备分为两种
    Protocol Devices(协议类设备)
    CharacterDevices(字符类设备)
    protocol_devices
    作为所有Protocol Devices的根节点,所有Protocol Devices驱动注册时调用
    rtdm_dev_register()
    后都会挂到
    protocol_devices
    上。

    xenomai中实时进程间通讯RTDM设备rtipc及其rtipc_driver,在

    drivers\xenomai\ipc\rtipc.c
    中如下:

    static struct rtdm_driver rtipc_driver = {
    .profile_info		=	RTDM_PROFILE_INFO(rtipc,
    RTDM_CLASS_RTIPC,
    RTDM_SUBCLASS_GENERIC,
    1),
    .device_flags		=	RTDM_PROTOCOL_DEVICE,
    .device_count		=	1,
    .context_size		=	sizeof(struct rtipc_private),
    .protocol_family	=	PF_RTIPC,	/*地址族*/
    .socket_type		=	SOCK_DGRAM,  /*socket类型*/
    .ops = {
    .socket		=	rtipc_socket,
    .close		=	rtipc_close,
    .recvmsg_rt	=	rtipc_recvmsg,
    .recvmsg_nrt	=	NULL,
    .sendmsg_rt	=	rtipc_sendmsg,
    .sendmsg_nrt	=	NULL,
    .ioctl_rt	=	rtipc_ioctl,
    .ioctl_nrt	=	rtipc_ioctl,
    .read_rt	=	rtipc_read,
    .read_nrt	=	NULL,
    .write_rt	=	rtipc_write,
    .write_nrt	=	NULL,
    .select		=	rtipc_select,
    },
    };
    
    static struct rtdm_device device = {
    .driver = &rtipc_driver,
    .label = "rtipc",
    };

    rtipc_driver
    中的
    rtdm_fd_ops
    我们就可以看出一二,创建一个rtipc socket后,对该socket的数据收发、读写等操作都会调用到
    rtdm_fd_ops
    内的
    rtipc_sendmsg()、rtipc_recvmsg()
    等函数。

    同样,如果需要自定义一个xenomai Protocol Devices,实现这些函数,为该设备设置好

    protocol_family
    socket_type
    后,我们的实时应用就可以通过调用socket(),然后xenomai RTDM通过
    (protocol_family<<32) | socket_type
    作为xnkey_t到该设备及对应的driver,来让该设备为我们服务。

    回到

    __rtdm_dev_socket()
    ,接下来调用
    __rtdm_anon_getfd
    完成在用户空间定义一个
    [rtdm-socket]
    的文件,将
    [rtdm-socket]
    rtdm_dumb_fops
    结合起来。

    int __rtdm_dev_socket(int protocol_family, int socket_type,
    int protocol)
    {
    ......
    ufd = __rtdm_anon_getfd("[rtdm-socket]", O_RDWR);
    ......
    ......
    ret = create_instance(ufd, dev, &context);
    ......
    }

    为什么要这样做呢?用户空间需要一个文件描述符来与内核rtdm_fd对应起来,ufd作为用户套接字socket,后面的代码会看到ufd成为红黑树上查找rtdm_fd的keyt_t,当使用socket接口对ufd操作时,到了内核里就会用ufd找到对应的rtdm_fd。但是直接对ufd使用read/write等操作是不允许的,所以还需要为ufd设置file_operation

    rtdm_dumb_fops
    ,
    rtdm_dumb_fops
    里的函数均打印一条警告信息,直接对ufd使用read/write等操作时就内核就会输出WARNING信息。

    static inline void warn_user(struct file *file, const char *call)
    {
    struct dentry *dentry = file->f_path.dentry;
    
    printk(XENO_WARNING
    "%s[%d] called regular %s() on /dev/rtdm/%s\n",
    current->comm, task_pid_nr(current), call + 5, dentry->d_name.name);
    }
    static ssize_t dumb_read(struct file *file, char  __user *buf,
    size_t count, loff_t __user *ppos)
    {
    warn_user(file, __func__);
    return -EINVAL;
    }
    
    .....
    const struct file_operations rtdm_dumb_fops = {
    .read		= dumb_read,
    .write		= dumb_write,
    .poll		= dumb_poll,
    .unlocked_ioctl	= dumb_ioctl,
    };

    接着调用

    create_instance()
    创建
    rtdm_dev_context
    并初始化对应的结构体,在RTDM中,struct rtdm_driver与struct rtdm_device描述了一个设备的共有抽象信息,但具体的设备有其操作的具体数据,称为实时设备的上下文
    rtdm_dev_context
    ,结构如下:

    struct rtdm_dev_context {
    struct rtdm_fd fd;
    
    /** Set of active device operation handlers */
    /** Reference to owning device */
    struct rtdm_device *device;
    
    /** Begin of driver defined context data structure */
    char dev_private[0];
    };

    其中成员

    fd
    类型为
    struct rtdm_fd
    ,其中记录着该设备的OPS,所属线程等信息。

    成员变量dev_private为私有数据的起始地址,至于设备的私有数据有多大,在rtdm_device用

    context_size
    表,对于rtipc,其大小为
    sizeof(struct rtipc_private)
    ,所以为rtipc创建rtdm_dev_context时分配的内存大小为
    sizeof(struct rtdm_dev_context) + rtipc_driver->context_size

    struct rtdm_fd
    如下

    struct rtdm_fd {
    unsigned int magic;  	/*RTDM_FD_MAGIC*/
    struct rtdm_fd_ops *ops;	/*RTDM设备可用的操作,*/
    struct cobalt_ppd *owner;	/*所属Process*/
    unsigned int refs;			/*打开计数*/
    int minor;
    int oflags;
    #ifdef CONFIG_XENO_ARCH_SYS3264
    int compat;
    #endif
    struct list_head cleanup;
    };
    • magic fd的类型 RTDM_FD_MAGIC
    • *ops 描述RTDM设备可用的操作。 这些处理程序由RTDM设备驱动程序(rtdm_driver)实现。
    • *owner该rtdm_fd所属的应用程序。
    • refs 记录该fd的引用次数,当为0时会触发执行
      ops->close()
    • minor
    • oflags
    • cleanup

    create_instance()
    执行完后各结构暂时如下:

    接着执行

    ops.socket()
    也就是
    rtipc_socket()
    ,传入参数为
    rtdm_fd
    protocol(IPCPROTO_XDDP)
    .

    if (dev->ops.socket) {
    ret = dev->ops.socket(&context->fd, protocol);
    ......
    }
    static int rtipc_socket(struct rtdm_fd *fd, int protocol)
    {
    struct rtipc_protocol *proto;
    struct rtipc_private *priv;
    int ret;
    
    if (protocol < 0 || protocol >= IPCPROTO_MAX)
    return -EPROTONOSUPPORT;
    
    if (protocol == IPCPROTO_IPC)
    /* Default protocol is IDDP */
    protocol = IPCPROTO_IDDP;
    
    proto = protocols[protocol - 1];
    if (proto == NULL)	/* Not compiled in? */
    return -ENOPROTOOPT;
    
    priv = rtdm_fd_to_private(fd);
    priv->proto = proto;
    priv->state = kmalloc(proto->proto_statesz, GFP_KERNEL);
    ......
    
    xnselect_init(&priv->send_block);
    xnselect_init(&priv->recv_block);
    
    ret = proto->proto_ops.socket(fd);
    ......
    return ret;
    }

    先看协议是不是xenomai支持的,如果协议类型为

    IPCPROTO_IPC
    ,那就是默认协议
    IPCPROTO_IDDP
    ,接着从数组中取出协议对应的
    rtipc_protocol* proto
    ,之前说过rtipc提供三种进程间通讯:IDDP、XDDP、BUFP,用结构体
    struct rtipc_protocol
    来描述它们,保存在数组
    rtipc_protocol
    中:

    static struct rtipc_protocol *protocols[IPCPROTO_MAX] = {
    #ifdef CONFIG_XENO_DRIVERS_RTIPC_XDDP
    [IPCPROTO_XDDP - 1] = &xddp_proto_driver,
    #endif
    #ifdef CONFIG_XENO_DRIVERS_RTIPC_IDDP
    [IPCPROTO_IDDP - 1] = &iddp_proto_driver,
    #endif
    #ifdef CONFIG_XENO_DRIVERS_RTIPC_BUFP
    [IPCPROTO_BUFP - 1] = &bufp_proto_driver,
    #endif
    };

    接着根据rtdm_fd得到

    rtdm_dev_context
    内的
    dev_private[0]
    ,这里先看一下
    struct rtipc_private
    各成员变量的意思:

    struct rtipc_private {
    struct rtipc_protocol *proto;
    DECLARE_XNSELECT(send_block);//struct xnselect send_block
    DECLARE_XNSELECT(recv_block);//struct xnselect recv_block
    void *state;
    };
    • proto指向具体的rtipc_protocol
    • send_block、send_block是链表,发送或接收阻塞时会插入该链表
    • state 与
      dev_private[0]
      类似,指向不同协议所需的而外空间。对于XDDP说指向
      sizeof(struct xddp_socket)
      大小内存。

    得到dev_private[0]后,强制类型转换为

    structr tipc_private *priv
    后开始初始化结构体
    tipc_private
    内各成员.最后调用具体协议的下的
    socket()
    ,传入参数fd,对应XDDP协议
    xddp_socket()
    ; 到此知道,实时应用对socket描述符的操作最后都是由实时设备驱动中具体函数来完成,后续的配置数据收发等都是按该路径进行执行。

    回到xddp socket():

    static int xddp_socket(struct rtdm_fd *fd)
    {
    struct rtipc_private *priv = rtdm_fd_to_private(fd);
    struct xddp_socket *sk = priv->state;
    
    sk->magic = XDDP_SOCKET_MAGIC;
    sk->name = nullsa;	/* Unbound */
    sk->peer = nullsa;
    sk->minor = -1;
    sk->handle = 0;
    *sk->label = 0;
    sk->poolsz = 0;
    sk->buffer = NULL;
    sk->buffer_port = -1;
    sk->bufpool = NULL;
    sk->fillsz = 0;
    sk->status = 0;
    sk->timeout = RTDM_TIMEOUT_INFINITE;
    sk->curbufsz = 0;
    sk->reqbufsz = 0;
    sk->monitor = NULL;
    rtdm_lock_init(&sk->lock);
    sk->priv = priv;
    
    return 0;
    }

    xddp_socket()
    主要初始化
    struct xddp_socket
    ,也很重要,后面会详细解析它。
    xddp_socket()
    执行完毕后回到
    __rtdm_dev_socket()
    ,接下来调用
    rtdm_fd_register()
    将rdtm_fd并注册到
    cobalt_ppd
    中。

    int __rtdm_dev_socket(int protocol_family, int socket_type,
    int protocol)
    {
    ......
    ret = rtdm_fd_register(&context->fd, ufd);
    .....
    return ufd;
    }
    int rtdm_fd_register(struct rtdm_fd *fd, int ufd)
    {
    struct rtdm_fd_index *idx;
    struct cobalt_ppd *ppd;
    spl_t s;
    int ret = 0;
    
    ppd = cobalt_ppd_get(0);
    idx = kmalloc(sizeof(*idx), GFP_KERNEL);
    ......
    idx->fd = fd;
    ......
    ret = xnid_enter(&ppd->fds, &idx->id, ufd);
    .....
    return ret;
    }

    3.2 rtdm_fd_index

    首先获取当前进程的

    struct cobalt_ppd
    ,然后分配一个
    struct rtdm_fd_index
    ,看名字知道rtdm_fd的index结构,怎么索引呢?通过传入的ufd,传入的ufd作为key,构造一个
    rtdm_fd_index
    ,然后插入
    ppd->fds
    ,
    ppd->fds
    时一颗红黑树,每个实时任务创建或打开的实时设备fd都是由fds来记录着。

    将ufd与rtdm_fd联系起来以后,socket函数执行完毕,返回

    ufd
    ,用户空间通过ufd发起内核调用时,就可通过ufd找到内核里相关的所有的结构。

    完成各数据结构分配关系链接后,下一步就可以对该socket进行配置了。解析

    setsockopt()
    函数之前,上面图中
    struct xddp_socket
    struct cobalt_ppd
    两个结构体还有没有介绍,如下:

    3.3 cobalt_ppd介绍

    struct cobalt_ppd
    (即Cobalt内核调度的实时进程的私有数据 ,Cobalt_process Private data),结构如下:

    struct cobalt_ppd {
    struct cobalt_umm umm;
    unsigned long mayday_tramp;
    atomic_t refcnt;
    char *exe_path;
    struct rb_root fds;
    };
    • umm
      该进程内管理的一片内存池,当实时任务内核上下文需要分配内存时,就会从该区域中获取。

      在xenomai中为避免向linux分配内存影响实时性,xenomai采取的方式是,先向linux分配所需的一片内存,然后再由自己管理该内存的分配释放,管理该内存池的分配释放算法是实时可预测的,从而达到不影响实时性的目的。当实时任务内核上下文需要分配内存时,就会从该区域中获取。关于实时内存堆的管理,可查看本博客其他文章.

    struct cobalt_umm {
    struct xnheap heap;/*内存池*
    atomic_t refcount; /*refcount是该片内存的使用计数*/
    void (*release)(struct cobalt_umm *umm);/*release释放函数*/
    };
    • refcnt
      cobalt_ppd引用计数,释放的时候使用.

    • fds
      是一棵红黑树,保存着该进程打开的实时驱动设备的文件描述符rtdm_fd,可以类比Linux中进程打开的文件描述符集,rtdm_fd结构上面说到过.

    xenomai内核中另外两个个heap需要区分一下:

    cobalt_kernel_ppd

    Cobalt_process.cobalt_ppd.cobalt_umm
    内的heap是每个Cobalt进程私有的,除此之外xenomai内核中还有一个全局的
    struct cobalt_ppd
    cobalt_kernel_ppd,供cobalt内核/内核线程工作过程中的内存分配。

    cobalt_heap:xenomai的系统内存池,XDDP数据缓冲区默认从该区域分配

    cobalt_heap,其大小可编译时配置或通过传递内核参数设置,在xenomai内核初始化时从linux分配内存,然后由xenomai初始化管理。

    static int __init xenomai_init(void)
    {
    .......
    ret = sys_init();
    ......
    }

    3.4 xddp_socket

    接着看

    struct xddp_socket
    ,是XDDP socket核心,管理着XDDP大部分资源,xddp_socket结构体成员及作用如下:

    struct xddp_socket {
    int magic;
    struct sockaddr_ipc name;
    struct sockaddr_ipc peer;
    
    int minor;
    size_t poolsz;
    xnhandle_t handle;
    char label[XNOBJECT_NAME_LEN];
    struct rtdm_fd *fd;			/* i.e. RTDM socket fd */
    
    struct xddp_message *buffer;
    int buffer_port;
    struct xnheap *bufpool;
    struct xnheap privpool;/*非系统内存池*/
    size_t fillsz;
    size_t curbufsz;	/* Current streaming buffer size */
    u_long status;
    rtdm_lock_t lock;
    
    nanosecs_rel_t timeout;	/* connect()/recvmsg() timeout */
    size_t reqbufsz;	/* Requested streaming buffer size */
    
    int (*monitor)(struct rtdm_fd *fd, int event, long arg);
    struct rtipc_private *priv;
    };
    • magic
      用来区分该socket类型XDDP_SOCKET_MAGIC
    • name
      绑定的rtipc套接字地址,
      peer
      表示目标端口。
    • minor
      RTIPC端口号。
    • privpool
      XDDP本地内存池,仅供xddp通讯使用,其大小为
      poolsz
      ,用户空间对该socket调用
      bind()
      前可通过
      setsocket()
      重复更其改大小,bind后无法更改。XDDP收发数据时的数据缓冲区可设置为从该区域分配,默认从xenomai的系统内存池cobalt_heap分配
    • bufpool
      数据缓冲区内存池指针,表示从哪个内存池分配数据缓冲区内存,如果设置了 XDDP本地内存池
      privpool
      ,则指向
      privpool
      ,否则指向xenomai系统内存池cobalt_heap
    • timeout
      实时任务
      connect()/recvmsg()
      超时时间
    • reqbufsz
      数据流缓冲区大小。
    • fillsz
      :缓冲区内的未读数据长度;
    • status
      记录XDDP socket 是否bind等状态信息
    • label
      设置该socket的label,设置label后linux端可通过label来与该socket通讯。

    这些设置与具体应用息息相关,了解低层原理后,结合具体应用场景来配置xdpp,能更好地发挥XDDP的性能。

    4.setsocketopt函数配置XDDP

    空间调用

    setsocketopt()
    主要就是对这个结构体中的变量进行设置和修改,需要注意的是,在bind操作前设置才有效,等bind的时候,会按该结构内的资源设置情况进行分配,要多大内存的缓冲区 ,使用的端口是什么,通信过程中从哪里分配内存,这些都是在bind时确定的,而且确定后就不能更改了。

    应用空间调用setsocketopt()来设置XDDP socktet,例如设置流缓冲区(XDDP_BUFSZ)大小1024字节。

    streamsz = 1024
    ret = setsockopt(s, SOL_XDDP, XDDP_BUFSZ,&streamsz, sizeof(streamsz));

    与socket()函数一样,是libcobalt库中的函数:

    /*lib\cobalt\rtdm.c*/
    COBALT_IMPL(int, setsockopt, (int fd, int level, int optname, const void *optval,
    socklen_t optlen))
    {
    struct _rtdm_setsockopt_args args = {
    SOL_XDDP, XDDP_BUFSZ, (void *)&streamsz, 4
    };
    int ret;
    
    ret = do_ioctl(fd, _RTIOC_SETSOCKOPT, &args);
    if (ret != -EBADF && ret != -ENOSYS)
    return set_errno(ret);
    
    return __STD(s

    与socket调用类似,先进行实时系统调用,如果参数非法,返回错误,才会转而尝试从glibc进行linux系统调用。在do_ioctl里直接进行实时系统调用

    sc_cobalt_ioctl

    static int do_ioctl(int fd, unsigned int request, void *arg)
    {
    
    pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype);
    ret = XENOMAI_SYSCALL3(sc_cobalt_ioctl,	fd, request, arg);
    pthread_setcanceltype(oldtype, NULL);
    return ret;
    }

    实时系统调用

    sc_cobalt_ioctl
    位于内核代码
    kernel\xenomai\posix\io.c

    COBALT_SYSCALL(ioctl, handover,
    (int fd, unsigned int request, void __user *arg))
    {
    return rtdm_fd_ioctl(fd, request, arg);
    }
    int rtdm_fd_ioctl(int ufd, unsigned int request, ...)
    {
    struct rtdm_fd *fd;
    fd = get_fd_fixup_mode(ufd);
    ....
    va_start(args, request);
    arg = va_arg(args, void __user *);
    va_end(args);
    
    set_compat_bit(fd);/*兼容32位应用处理*/
    ....
    err = fd->ops->ioctl_rt(fd, request, arg);
    ...
    rtdm_fd_put(fd);
    ....
    return err;
    }

    第一个参数ufd是创建socket时返回的ufd,上一节已经与rtdm_fd联系起来,所以直接通过

    get_fd_fixup_mode()
    就能得到
    struct rtdm_fd
    ,进而获取所有相关信息。

    接着调用fd->ops->ioctl_rt,对于XDDP是

    xddp_ioctl()
    。xddp_ioctl里首先判断接着调用
    __xddp_ioctl

    static int xddp_ioctl(struct rtdm_fd *fd,
    unsigned int request, void *arg)
    {
    int ret;
    ......
    ret = __xddp_ioctl(fd, request, arg);
    }
    
    return ret;
    }
    static int __xddp_ioctl(struct rtdm_fd *fd,
    unsigned int request, void *arg)
    {
    struct rtipc_private *priv = rtdm_fd_to_private(fd);
    struct sockaddr_ipc saddr, *saddrp = &saddr;
    struct xddp_socket *sk = priv->state;
    int ret = 0;
    
    switch (request) {
    COMPAT_CASE(_RTIOC_CONNECT): /*connect操作*/
    ret = rtipc_get_sockaddr(fd, &saddrp, arg);
    ret = __xddp_connect_socket(sk, saddrp);
    break;
    
    COMPAT_CASE(_RTIOC_BIND):/*bind操作*/
    ret = rtipc_get_sockaddr(fd, &saddrp, arg);
    .......
    ret = __xddp_bind_socket(priv, saddrp);
    break;
    
    COMPAT_CASE(_RTIOC_GETSOCKNAME):/*获取socket name*/
    ret = rtipc_put_sockaddr(fd, arg, &sk->name);
    break;
    
    COMPAT_CASE(_RTIOC_GETPEERNAME):/*获取socket name*/
    ret = rtipc_put_sockaddr(fd, arg, &sk->peer);
    break;
    
    COMPAT_CASE(_RTIOC_SETSOCKOPT):/*配置socket*/
    ret = __xddp_setsockopt(sk, fd, arg);
    break;
    
    COMPAT_CASE(_RTIOC_GETSOCKOPT):/*获取socket配置*/
    ret = __xddp_getsockopt(sk, fd, arg);
    break;
    
    case _RTIOC_LISTEN: /*不支持*/
    ret = -EOPNOTSUPP;
    break;
    case _RTIOC_SHUTDOWN:
    ret = -ENOTCONN;
    break;
    ......
    }
    return ret;
    }

    __xddp_ioctl
    主要根据request来进行操作,接着执行
    __xddp_setsockopt
    进行具体配置:

    static int __xddp_setsockopt(struct xddp_socket *sk,
    struct rtdm_fd *fd,
    void *arg)
    {
    int (*monitor)(struct rtdm_fd *fd, int event, long arg);
    struct _rtdm_setsockopt_args sopt;
    struct rtipc_port_label plabel;
    struct timeval tv;
    rtdm_lockctx_t s;
    size_t len;
    int ret;
    
    ret = rtipc_get_sockoptin(fd, &sopt, arg);
    ......
    if (sopt.level == SOL_SOCKET) {
    switch (sopt.optname) {
    case SO_RCVTIMEO:
    ret = rtipc_get_timeval(fd, &tv, sopt.optval, sopt.optlen);
    ........
    sk->timeout = rtipc_timeval_to_ns(&tv);
    break;
    ......
    }
    return ret;
    }
    
    switch (sopt.optname) {
    
    case XDDP_BUFSZ:/*配置buf size*/
    ........
    break;
    
    case XDDP_POOLSZ:   /*设置POOLSZ大小 */
    ........
    break;
    
    case XDDP_MONITOR: /*设置 monitor 函数(仅内核应用支持)*/
    ......
    break;
    
    case XDDP_LABEL:/*设置 label*/
    ......
    break;
    
    default:
    ret = -EINVAL;
    }
    return ret;
    }

    4.1 设置timeout

    根据传入的第2、3个参数来决定配置什么,先判断是否是设置

    connect()/recvmsg()
    超时时间,并设置。

    4.2 设置流缓冲区大小:

    上面说到XDDP提供了流缓冲功能,可以将多次发送的数据累积后作为整个数据包发送。XDDP_BUFSZ就是用来设置该缓冲区的最大大小的。

    case XDDP_BUFSZ:
    ret = rtipc_get_length(fd, &len, sopt.optval, sopt.optlen);
    if (ret)
    return ret;
    if (len > 0) {
    len += sizeof(struct xddp_message);
    if (sk->bufpool &&
    len > xnheap_get_size(sk->bufpool)) {/*大于可分配内存,返回错误*/
    return -EINVAL;
    }
    }
    rtdm_lock_get_irqsave(&sk->lock, s);
    sk->reqbufsz = len;
    if (len != sk->curbufsz &&
    !test_bit(_XDDP_SYNCWAIT, &sk->status) &&
    test_bit(_XDDP_BOUND, &sk->status))
    ret = __xddp_resize_streambuf(sk); //多次分配,释放原来的然后从xnheap 重新分配
    rtdm_lock_put_irqrestore(&sk->lock, s);
    break;

    首先从用户空间得到要设置的缓冲区大小保存到变量len,整个缓冲区为

    struct xddp_message
    ,由于数据累积期间需要一个message head来管理记录缓冲区内数据的size、offset等信息,这个结构为
    struct xnpipe_mh
    位于
    struct xddp_message
    头部,接着才是缓冲区的数据区,结构如下。

    struct xnpipe_mh {
    size_t size;
    size_t rdoff;
    struct list_head link;
    };
    struct xddp_message {
    struct xnpipe_mh mh;
    char data[];
    };

    由于默认从cobalt_heap中分配缓冲区内存,应用需要的缓冲区大小可能大于cobalt_heap的大小,所以建议先设置XDDP本地内存池,然后再配置缓冲区大小。

    4.3 设置 XDDP使用的内存池

    上面介绍过成员变量,sk->bufpool 数据缓冲区内存池指针,表示从哪个内存池分配数据缓冲区内存,如果设置了 XDDP本地内存池privpool,则指向privpool ,否则指向xenomai系统内存池cobalt_heap。下面看设置 XDDP本地内存池privpool:

    case XDDP_POOLSZ:
    ret = rtipc_get_length(fd, &len, sopt.optval, sopt.optlen);
    ......
    cobalt_atomic_enter(s);
    if (test_bit(_XDDP_BOUND, &sk->status) ||
    test_bit(_XDDP_BINDING, &sk->status))
    ret = -EALREADY;
    else
    sk->poolsz = len;
    cobalt_atomic_leave(s);
    break;

    同样处理传入的参数,将要设置的内存池大小保存到len,判断该socket是否已经bind,因为privpool管理的内存是在bind操作时才真正分配的,现在只是先记录需要分配的大小。如果已经bind是不能再修改带大小的。

    4.4 设置XDDP label

    除了使用固定端口外,还可通过设置xddp的socket label,linux可通过label来和该 XDDP socket通讯,设置label后bind时其RTIPC端口是系统自动分配的

    case XDDP_LABEL:
    if (sopt.optlen < sizeof(plabel))
    return -EINVAL;
    if (rtipc_get_arg(fd, &plabel, sopt.optval, sizeof(plabel)))
    return -EFAULT;
    cobalt_atomic_enter(s);
    if (test_bit(_XDDP_BOUND, &sk->status) ||
    test_bit(_XDDP_BINDING, &sk->status))
    ret = -EALREADY;
    else {
    strcpy(sk->label, plabel.label);
    sk->label[XNOBJECT_NAME_LEN-1] = 0;
    }
    cobalt_atomic_leave(s);
    break;

    先进行参数检查,然后将label拷贝到

    sk->label[]
    中。

    到此针对 xddp 的setsocketopt操作解析完毕,大部分操作为配置

    xddp_socket
    这个结构体;

    标签: