Como evitar que o DTR seja aberto para cdc_acm?

Quando um processo userland está abrindo um dispositivo serial como /dev/ttyS0ou /dev/ttyACM0, o linux aumentará as DTR/RTSlinhas por padrão e as descartará ao fechá-lo.

Ele faz isso chamando um dtr_rtsretorno de chamada definido pelo driver.

Infelizmente, ainda não existe nenhum sysctl ou similar que permita desabilitar esse comportamento irritante (pouco útil hoje em dia), então a única coisa que funciona é remover esse callback da tty_port_operationsestrutura do driver e recompilar o módulo do driver.

Você pode fazer isso para o cdc-acmdriver comentando esta linha :

--- drivers/usb/class/cdc-acm.c~
+++ drivers/usb/class/cdc-acm.c
@@ -1063,7 +1063,7 @@
 }

 static const struct tty_port_operations acm_port_ops = {
-       .dtr_rts = acm_port_dtr_rts,
+       /* .dtr_rts = acm_port_dtr_rts, */
        .shutdown = acm_port_shutdown,
        .activate = acm_port_activate,
        .destruct = acm_port_destruct,

Isso não impedirá que você use as DTR/RTSlinhas por meio de ioctls seriais como TIOCMSET, TIOCMBIC, TIOCMBIS, que serão tratadas pelos acm_tty_tiocmset()callbacks , etc da acm_opsestrutura, como de costume.

Hacks semelhantes podem ser usados ​​com outros drivers; Eu pessoalmente usei isso com o PL2303driver usb -> serial.

[A diferença é informativa; não será aplicado diretamente porque este site altera guias e espaços em branco]

Eu acho que há uma boa solução alternativa que resolve o problema. Em vez de ler os dados do dispositivo /dev/ttyUSB0 ou /dev/ttyACM0, eles podem ser lidos do pipe nomeado, por exemplo, /tmp/arduino e o programa simples (abaixo) copiaria os dados do dispositivo para o pipe e manteria o dispositivo aberto (evitando assim configurar DTR alto). Isso também evita lidar com todas as dificuldades de leitura do dispositivo. Com o pipe nomeado, ferramentas como cat, less -f podem ser usadas ou apenas qualquer programa com padrão open + read sem a necessidade de emitir comandos ioctl para controlar tty. O programa para copiar o dispositivo para o pipe seria executado, por exemplo, como um serviço inicial e copiar dados do dispositivo para o pipe (e talvez produzir alguns logs). O programa tem que cuidar do sinal SIGPIPE, para evitar que seja fechado ao fechar qualquer processo de leitura de pipe. A carga no servidor seria insignificante devido ao bloqueio intencional da entrada via fcntl. Eu testei e parece estar funcionando bem. Estou realmente tentando resolver o mesmo problema com a interface do Arduino. O bom efeito colateral é que a reinicialização do Arduino pode ser feita simplesmente reiniciando o serviço upstart sempre que necessário, pois define o DTR alto.

#include <unistd.h>
#include <string.h>
#include <signal.h>
#include <fcntl.h>

/* for simplicity, most error handling is ommited, make sure you add it before using in production code */
void ignore_signal(int sig)
{
        static struct sigaction _sigact;
        memset(&_sigact, 0, sizeof(_sigact));
        _sigact.sa_handler = SIG_IGN;
        sigaction(sig, &_sigact, NULL);
}

int main()
{
        ignore_signal(SIGPIPE);

        int flags;
        flags = fcntl(0, F_GETFL, 0) & ~O_NONBLOCK;
        fcntl(0, F_SETFL, flags);


        char c;
        int n;
        while(1)
        {
                n = read(0,&c,1);
                if(n!=1)
                {
                        sleep(1);
                }
                else
                {
                        write(1,&c,1); /* ignoring the case that return code = -1 and errno = EPIPE means that data from Arduino are lost whenever pipe is not read */
                        write(2,&c,1);
                }
        }
        return 0;
}

O script de shell para iniciá-lo seria (precisa ser reimplementado como serviço upstart):

#!/bin/bash

DEV=/dev/ttyUSB0
PIPE=/tmp/arduino
LOG=/var/log/arduino.log

if test ! -p $PIPE
then
    rm -f $PIPE
    mkfifo $PIPE
fi

./my_dd <$DEV >$PIPE 2>>$LOG &
dd if=$PIPE of=/dev/null count=0 bs=1

Acho que o arquivo logrotate precisa usar copytruncate, porque o arquivo ainda está aberto (não tive chance de testar isso):

/var/log/arduino.log {
  rotate 5
  daily
  compress
  missingok
  notifempty
  create 640 root root
  copytruncate
}

Nota adicional: Enquanto isso, percebi que, para evitar o tubo quebrado, provavelmente poderia ser alcançado com o uso de cat ou dd em combinação com o comando trap com o parâmetro PIPE, que estaria filtrando o sinal SIGPIPE também. A solução acima funciona para mim, então não estava experimentando o comando trap para obter resultados comparáveis.