如何validationprimefaces写入?

我已经在S [O | F | U]networking和其他地方努力search,相信这是一个不常见的问题。 我正在使用一个运行Debian Linux 2.6.28-4的Atmel AT91SAM9263-EK开发板(ARM926EJ-S内核,ARMv5指令集)。 我正在使用(我相信)tty驱动程序与RS-485串行控制器进行通信 。 我需要确保写入和读取是primefaces的。 有几行源代码(列在本文后面的内核源代码安装目录下面)暗示或暗示了这一点。

有什么办法可以validation写入/读取这个设备实际上是一个primefaces操作吗? 或者,/ dev / ttyXX设备是否被认为是FIFO并且参数在那里结束? 仅仅相信代码正在执行它所做的这个声明似乎是不够的 – 就在今年2月份,freebsd被certificate缺less小规模的primefaces写入 。 是的,我意识到,freebsd是不完全一样的Linux,但我的意思是,这是不伤害的是要小心。 我所能想到的就是不断发送数据并寻找一个排列 – 我希望有一些更科学的,理想的是确定性的。 不幸的是,在大学时代,我并没有记得我的并发编程课程。 我会彻底地感谢一个正确的方向一巴掌或推。 如果您select回复,请提前感谢您。

亲切的问候,

Jayce

司机/炭/在tty_io.c:1087

void tty_write_message(struct tty_struct *tty, char *msg) { lock_kernel(); if (tty) { mutex_lock(&tty->atomic_write_lock); if (tty->ops->write && !test_bit(TTY_CLOSING, &tty->flags)) tty->ops->write(tty, msg, strlen(msg)); tty_write_unlock(tty); } unlock_kernel(); return; } 

拱/臂/包括/ ASM / bitops.h:37

 static inline void ____atomic_set_bit(unsigned int bit, volatile unsigned long *p) { unsigned long flags; unsigned long mask = 1UL << (bit & 31); p += bit >> 5; raw_local_irq_save(flags); *p |= mask; raw_local_irq_restore(flags); } 

司机/串口/ serial_core.c:2376

 static int uart_write(struct tty_struct *tty, const unsigned char *buf, int count) { struct uart_state *state = tty->driver_data; struct uart_port *port; struct circ_buf *circ; unsigned long flags; int c, ret = 0; /* * This means you called this function _after_ the port was * closed. No cookie for you. */ if (!state || !state->info) { WARN_ON(1); return -EL3HLT; } port = state->port; circ = &state->info->xmit; if (!circ->buf) return 0; spin_lock_irqsave(&port->lock, flags); while (1) { c = CIRC_SPACE_TO_END(circ->head, circ->tail, UART_XMIT_SIZE); if (count < c) c = count; if (c <= 0) break; memcpy(circ->buf + circ->head, buf, c); circ->head = (circ->head + c) & (UART_XMIT_SIZE - 1); buf += c; count -= c; ret += c; } spin_unlock_irqrestore(&port->lock, flags); uart_start(tty); return ret; } 

另外,从这个男人写(3)文档:

尝试写入pipe道或FIFO有几个主要特点:

  • primefaces/非primefaces:如果在一个操作中写入的全部数据不与来自任何其他进程的数据交错,则写入是primefaces的。 当有多个写入者将数据发送到一个阅读器时,这非常有用。 应用程序需要知道有多大的写请求可以预期primefaces执行。 这个最大值被称为{PIPE_BUF}。 IEEE Std 1003.1-2001的这一卷没有说明大于{PIPE_BUF}字节的写入请求是否是primefaces的,但是要求写入{PIPE_BUF}或更less的字节应该是primefaces的。

我认为在技术上,设备不是FIFO,所以你所引用的保证应该适用。

你是否担心部分写入和读取过程中,或者你是否正在从不同的进程读取和/或写入相同的设备? 假设后者,你可能会更好地执行某种代理进程。 代理完全拥有该设备并执行所有的读写操作,从而完全避免了多进程的原子性问题。

简而言之,我建议不要试图验证“从这个设备读取/写入实际上是一个原子操作”。 如果后期版本的linux(或者不同的o / s)完全不能按照你所需要的方式实现原子性,那么这样做会很困难。

我认为PIPE_BUF是正确的。 现在,小于PIPE_BUF字节的写入可能不是原子的,但是如果它们不是它是一个操作系统错误。 我想你可以问在这里如果一个操作系统已知的错误。 但是,真的,如果它有这样的错误,它应该立即修复。

如果你想自己写更多的PIPE_BUF ,我觉得你运气不好。 我认为除了应用程序的协调和合作之外,没有任何办法可以确保更大尺寸的写入是以原子方式进行的。

解决这个问题的一个办法就是把你自己的进程放在设备前面,并确保每个想要写入设备的人联系进程并把数据发送给它。 那么你可以在原子性保证方面为你的应用做任何有意义的事情。