Como corrigir o kernel para reduzir a lacuna VTIME para a API uart termios?

Preciso de ajuda para encontrar um patch de kernel para obter um VTIME da API tty termios inferior a 100ms, ...

Um patch do kernel Linux é necessário...

Tal patch para o kernel é imprudente porque mudaria a API do espaço do usuário. O Linux se esforça para manter uma API consistente, e o patch solicitado provavelmente quebraria os aplicativos existentes.

Mesmo que tal patch para o kernel não tenha alterado a API, não é provável que seja confiável e atinja seu(s) objetivo(s) não declarado(s). Você não pode ou não deve confiar apenas nas configurações de VMIN e VTIME para detectar mensagens separadas por tempo.

Se a UART utilizar um FIFO para armazenar em buffer os dados de entrada, esse buffer de hardware ocultará o espaçamento entre caracteres que o software pode detectar. Da mesma forma, quando o driver UART estiver usando DMA para armazenar os dados recebidos, o tempo entre caracteres será obscurecido.

O manuseio dos termios está pelo menos uma camada completa acima do driver do dispositivo UART. A camada termios simplesmente não vê as mesmas informações de tempo que estavam na conexão depois que os bytes são manipulados/armazenados em buffer pelo UART e seu driver.

A API serial do Microsoft Windows é capaz de configurar até 1 ms, mas não o Linux. Portanto, o Windows é melhor para processamento bruto de porta serial.

Se você acha que o Windows é mais adequado para o seu aplicativo, você deve usá-lo. Mas esteja avisado de que o que é anunciado não é necessariamente o que você receberá. Essa API do Windows apenas anuncia a especificação de um tempo limite com precisão de milissegundos . Isso não significa que você realmente obterá tal precisão . Por exemplo, existem avisos de que:

Os intervalos de tempo limite são medidos em relação ao relógio do sistema e a precisão da medição do tempo limite é limitada pela granularidade do relógio do sistema . Como resultado, um tempo limite pode ocorrer entre um tique do relógio do sistema antes e um tique depois do intervalo de tempo limite especificado , dependendo de onde exatamente os horários de início e término desse intervalo caem entre os tiques do relógio do sistema. Os tempos limite poderão ocorrer ainda mais tarde se o processamento de interrupção do relógio do sistema for atrasado pelo processamento de interrupção para outros dispositivos. Se um intervalo de tempo limite especificado for próximo ou menor que o período entre os tiques do relógio do sistema, o tempo limite poderá ocorrer imediatamente, sem atraso .

Acho que o problema está aqui, talvez seja por isso que a fila read_wait não foi ativada.

Não, você persiste em procurar no lugar errado.
Como tentei apontar para você anteriormente (referindo-me a esta postagem ), a solução confiável requer um temporizador para detectar um receptor UART ocioso. No entanto, mesmo quando o hardware UART implementa um tempo limite do receptor (em dois drivers Linux que revisei), o recurso é usado apenas para abortar a operação DMA atual/ativa.

Como o tempo limite do receptor (possivelmente) detectou o fim de uma mensagem separada por tempo, esse evento/informação precisa ser transmitido para a camada termios quando o driver UART passa os dados recebidos. Esta é a informação que falta que o termios precisa para uma nova variação do modo VMIN > 0bruto VTIME > 0. Em vez de termios verificar o tempo limite entre caracteres, nesta nova variação o driver UART precisa indicar esse evento de tempo limite com os dados recebidos.
Esse não é um patch de kernel trivial.

Esperançosamente, encontrei algumas explicações e concluí que estamos diante de uma obsolência de APIs que implicava ser contornada pelo consumo excessivo de CPUs.

A granularidade do tempo limite VTIME foi historicamente definida como a unidade de intervalo entre bytes (VTIME definido pelo POSIX = 100ms). O intervalo entre bytes usado atualmente pelo Linux ainda corresponde a uma linha serial de 110 bauds ( cento e dez ). Mas hoje em dia, por exemplo, com uma linha serial de 115.200 bauds, a duração do TX de um byte é de aproximadamente 100 µs (microssegundo).

Alan Cox: RE: comportamento dos termos VMIN e VTIME

Está muito bem definido. Ele foi projetado para otimizar operações seriais de blocos (uucp e similares)

VMIN - quantidade de bytes que você espera deste pacote VTIME - quando desistir de esperar

O formulário 0, VTIME também está sendo usado para fazer polling em SYSV antigo que não possuía select/poll

POSIX 2007 junho §11.1.7 Processamento de entrada em modo não canônico

No processamento de entrada no modo não canônico, os bytes de entrada não são montados em linhas e o processamento de apagamento e eliminação não deve ocorrer. Os valores dos membros MIN e TIME da matriz c_cc são usados ​​para determinar como processar os bytes recebidos. POSIX.1-200x não especifica se a configuração de O_NONBLOCK tem precedência sobre as configurações MIN ou TIME. Portanto, se O_NONBLOCK estiver definido, read() poderá retornar imediatamente, independentemente da configuração de MIN ou TIME. Além disso, se nenhum dado estiver disponível, read() pode retornar 0 ou retornar −1 com errno definido como [EAGAIN]. MIN representa o número mínimo de bytes que devem ser recebidos quando a função read() retornar com sucesso. TIME é um temporizador de granularidade de 0,1 segundo usado para atingir o tempo limite de transmissões de dados em rajadas e de curto prazo.Se MIN for maior que {MAX_INPUT}, a resposta à solicitação será indefinida.

O Manual de Referência da Biblioteca GNU C, para versão 2.37, §17.4.10 Entrada Não Canônica

Macro: int VTIME Este é o subscrito do slot TIME no array c_cc. Assim, termios.c_cc[VTIME] é o próprio valor.

O intervalo TIME só é significativo no modo de entrada não canônico; especifica quanto tempo esperar pela entrada antes de retornar, em unidades de 0,1 segundos. [...]

MIN é zero, mas TIME tem um valor diferente de zero: neste caso, a leitura aguarda o tempo TIME para que a entrada fique disponível; a disponibilidade de um único byte é suficiente para satisfazer a solicitação de leitura e fazer com que a leitura retorne. Quando retorna, retorna quantos caracteres estiverem disponíveis, até o número solicitado. Se nenhuma entrada estiver disponível antes que o temporizador expire, read retornará um valor zero.

2005 The SCO Group, Inc. § Processamento de entrada em modo não canônico

1. (MIN>0, TEMPO>0).

Como TIME>0, ele serve como um temporizador entre bytes ativado no recebimento do primeiro byte de dados e redefinido no recebimento de cada byte de dados. MIN e TIME interagem da seguinte forma:

• Assim que um byte de dados é recebido, o temporizador entre bytes é iniciado (lembre-se de que o temporizador é redefinido no recebimento de cada byte).
• Se MIN bytes de dados forem recebidos antes que o temporizador entre bytes expire , a leitura será concluída com êxito.
• Se o temporizador entre bytes expirar antes que MIN bytes de dados sejam recebidos, a leitura transferirá todos os bytes recebidos até então.

Quando TIME expira, uma leitura transfere pelo menos um byte de dados porque o temporizador entre bytes é ativado se e somente se um byte de dados for recebido. Um programa que usa este caso deve esperar que pelo menos um byte de dados seja lido antes de prosseguir. No caso (MIN>0, TIME>0), uma leitura é bloqueada até que o recebimento de um byte de dados ative MIN e TIME, ou um sinal interrompa a leitura. Assim, a leitura transfere pelo menos um byte de dados.

[...]

3. (MIN=0, TEMPO>0).

Como MIN=0, TIME não serve mais como um temporizador entre bytes, mas agora serve como um temporizador de leitura ativado quando uma leitura é processada (no cânone). Uma leitura é concluída com êxito assim que qualquer byte de dados for recebido ou o cronômetro de leitura expirar. Uma leitura não transfere nenhum byte de dados se o temporizador de leitura expirar. Se o cronômetro de leitura não expirar, uma leitura será concluída com êxito se e somente se alguns bytes de dados forem recebidos. No caso (MIN=0, TIME>0), a leitura não bloqueia indefinidamente aguardando um byte de dado. Se nenhum byte de dados for recebido dentro de TIME*0,10 segundos após o início da leitura, ele retornará 0 sem leitura de dados. Se o buffer contiver dados quando uma leitura for iniciada, o cronômetro de leitura será iniciado como se tivesse recebido os dados imediatamente. MIN e TIME são úteis quando um programa pode assumir que os dados não estão disponíveis após um intervalo de TIME e outro processamento pode ser feito antes que os dados estejam disponíveis.

Para propor um patch que mantenha a compatibilidade da API do kernel, acho que uma solução de desvio é a principal possível: é usar o valor do parâmetro VEOF (valor de char não assinado não utilizado) do modo CANON para ajustar o VTIME (adicionar um fator de divisão ao valor de tempo limite antes de aplicar a função schedule_timeout ), que será aplicado à função de leitura do modo NÃO-CANON.

Use o valor VEOF que não é usado no modo não canon: https://elixir.bootlin.com/linux/latest/source/include/linux/tty.h#L39

Aplique a divisão aqui: por exemplo, se o valor VEOF for diferente do valor padrão, aplique para reduzir o tempo limite de VTIME. https://elixir.bootlin.com/linux/latest/source/drivers/tty/n_tty.c#L2196