Andrey Pro's questions

O que é uma thread estacionada no contexto do kernel Linux? Uma thread que está em TASK_PARKEDestado?

Como esse estado difere de TASK_INTERRUPTIBLEe TASK_UNINTERRUPTIBLE?

De qual estado uma thread pode ser despertada mais rapidamente? Geralmente, e em casos específicos, se usada para espera: kthread_parkme / kthread_unparkem vez de [s]wait_event_... / [s]wake_up_...]?

Sei que as filas de espera aceitam vários garçons, mas estou interessado apenas em um único par de pessoas dormindo/acordando.

Como posso descobrir desde qual versão do Linux uma função/macro da API do kernel está disponível ou sofreu alterações significativas (foi removida, houve alteração no tipo ou número de argumentos)?

Por exemplo, ao olhar a versão recente do , scatterlist.hme deparei com sg_alloc_table_from_pages_segment, que tem exatamente a funcionalidade necessária para meu módulo do kernel (driver). No entanto, a função, para minha decepção, ainda não está disponível na versão 5.10 para a qual o módulo do kernel foi desenvolvido, e terei que encontrar uma solução alternativa. Ainda assim, desejo oferecer suporte a futuras versões do kernel, caso realizemos uma atualização.

Normalmente, esses casos são tratados com cercas de pré-processador

#if LINUX_VERSION_CODE >= KERNEL_VERSION(...)
/*Version-specific implementation*/
#endif

Mas para aplicar esse padrão, preciso encontrar a versão do kernel na qual a função foi adicionada. Escanear manualmente todas as versões intermediárias do arquivo de cabeçalho seria uma tarefa de Sísifo.

Tenho uma máquina de desenvolvimento rodando Debian 11, que atualmente é nosso ambiente padrão para hosts de equipamentos. Eu uso VNC (servidor TigerVNC) para acessá-lo remotamente do meu computador de trabalho. O problema é que o TigerVNC que vem com o Debian 11 tem um bug muito chato , que interfere no meu trabalho.

O bug foi corrigido há muito tempo, mas não há um backport oficial e, até onde sei, os backports para o Debian 11 já expiraram.

Então a única maneira de obter a correção é fazer o backport do TigerVNC manualmente.

Tentei seguir o guia de backporting de Faheem Mitha , porque parece ser o método mais adequado para este caso, que requer configuração e build específicos do Debian. Consegui chegar ao Passo 4:

 debuild -uc -us
 dpkg-buildpackage -us -uc -ui
dpkg-buildpackage: info: source package tigervnc
dpkg-buildpackage: info: source version 1.12.0+dfsg-8~bpo11+1
dpkg-buildpackage: info: source distribution bullseye-backports
dpkg-buildpackage: info: source changed by 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
dpkg-source: info: using options from tigervnc-1.12.0+dfsg/debian/source/options: --single-debian-patch --create-empty-orig
dpkg-checkbuilddeps: error: Unmet build dependencies: libxft-dev libxcursor-dev libxrandr-dev libxdamage-dev libwrap0-dev xorg-server-source (>= 2:21) xserver-xorg-dev appstream quilt bison flex x11proto-dev (>= 2021.5) libxcvt-dev libxfont-dev (>= 1:2.0.1) libxkbfile-dev (>= 1:0.99.1) libpciaccess-dev (>= 0.12.901) libgcrypt-dev libudev-dev (>= 151-3) libselinux1-dev (>= 2.0.80) libaudit-dev libdrm-dev (>= 2.4.107-5~) mesa-common-dev libunwind-dev libxmuu-dev (>= 1:0.99.1) libxrender-dev (>= 1:0.9.0) libxi-dev (>= 2:1.8) libxpm-dev (>= 1:3.5.3) libxaw7-dev (>= 1:0.99.1) libxmu-dev (>= 1:0.99.1) libxtst-dev (>= 1:0.99.1) libxres-dev (>= 1:0.99.1) libxfixes-dev (>= 1:3.0.0) libxv-dev libxinerama-dev libxshmfence-dev (>= 1.1) libepoxy-dev libegl-dev (>= 1.3.2) libgbm-dev (>= 10.2) libbsd-dev libdbus-1-dev (>= 1.0) libsystemd-dev
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui failed

sudo apt-get build-dep tigervnc-standalone-server=1.12.0+dfsg-8
Reading package lists... Done
Picking 'tigervnc' as source package instead of 'tigervnc-standalone-server'
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:tigervnc : Depends: xorg-server-source (>= 2:21) but 2:1.20.11-1+deb11u14 is to be installed
                      Depends: x11proto-dev (>= 2021.5) but 2020.1-1 is to be installed
                      Depends: libxcvt-dev but it is not installable
                      Depends: libdrm-dev (>= 2.4.107-5~) but 2.4.104-1 is to be installed
                      Depends: libxi-dev (>= 2:1.8) but 2:1.7.10-1 is to be installed
E: Unable to correct problems, you have held broken packages.

No entanto, não entendi no guia o que exatamente devo fazer sobre dependências não atendidas. Devo diminuir a versão necessária em debian/control? E, em particular, como lidar com libxcvt-dev que está marcado como desinstalável?

Drivers de dispositivo Linux, 3ª edição afirma:

se o método llseek estiver faltando nas operações do dispositivo, a implementação padrão no kernel executa buscas modificando filp->f_pos

No entanto, tenho um dispositivo de caractere para o qual o driver não implementa lseek. Aqui estão as definições de op de arquivo para esse tipo de dispositivo: https://github.com/Xilinx/dma_ip_drivers/blob/master/XDMA/linux-kernel/xdma/cdev_ctrl.c

Mas tentar lseek neste dispositivo retorna ESPIPE:

#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <errno.h>
int main(int argc, char** argv) {
    uint32_t val=0x12345678;
    int fid=open("/dev/xdma0_user", O_RDWR);
    off_t lseek_ret=lseek(fid, 0x8ul, SEEK_SET);
    if (lseek_ret <0)
        fprintf(stderr, "Seek result: %d, errno: %s (%d)\n", lseek_ret, strerror(errno), errno );
    unsigned int c=write(fid, &val, sizeof(val));
    printf("written %u bytes\n", c);
    close(fid);
    return (0);
}

Saída:

Seek result: -1, errno: Illegal seek (29)
written 4 bytes

Não consigo entender como isso acontece. Não pode vir do driver: ESPIPE nem é mencionado em lugar nenhum, então deve vir do kernel, o que contradiz a citação acima.

O comportamento padrão foi alterado? Ele pode ser configurado de alguma forma? Como pode ser visto o que o kernel realmente faz (idealmente código fonte)?

A versão do kernel é 5.10 (Debian 11).