Comment vérifier les écritures atomiques?

Question

J'ai cherché avec diligence (à la fois dans le réseau S [O | F | U] et ailleurs) et je crois que c'est une question rare. Je travaille avec une carte de développement Atmel AT91SAM9263-EK (noyau ARM926EJ-S, jeu d'instructions ARMv5) sous Debian Linux 2.6.28-4. J'écris en utilisant (je crois) le tty driver pour parler à un RS-485 serial controller. Je dois m'assurer que les écritures et les lectures sont atomiques. Plusieurs lignes de code source (listées sous la fin de ce post par rapport au répertoire d'installation de la source du noyau) impliquent ou implicitement cela.

Est-il possible de vérifier que l'écriture/la lecture vers/depuis cet appareil est réellement une opération atomique? Ou, le périphérique/dev/ttyXX est-il considéré comme une FIFO et l'argument se termine-t-il? Il ne semble pas suffisant de simplement croire que le code applique cette revendication - aussi récemment que février de cette année, freebsd était demonstrated to lack atomic writes for small lines. Oui, je me rends compte que freebsd n'est pas exactement la même chose que Linux, mais ce que je veux dire, c'est que ça ne fait pas de mal d'en être bien sûr. Tout ce que je peux penser est de continuer à envoyer des données et de chercher une permutation - j'espérais quelque chose d'un peu plus scientifique et, idéalement, déterministe. Malheureusement, je ne me souviens précisément de rien de mes cours de programmation simultanée à l'époque universitaire. J'apprécierais profondément une gifle ou une poussée dans la bonne direction. Merci d'avance si vous choisissez de répondre.

Cordialement,

Jayce

drivers/char/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; 
} 

arc/bras/include/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); 
} 

pilotes/série/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; 
} 

En outre, à partir de la documentation écriture de l'homme (3):

Une tentative d'écrire à un tuyau ou FIFO a plusieurs caractéristiques principales:

• Atomique/non-atomique: A écrire est atomique si la quantité totale écrite en une opération n'est pas entrelacée avec les données d'un autre processus. Ceci est utile lorsque plusieurs auteurs envoient des données à un seul lecteur. Les applications doivent connaître la taille de la requête d'écriture qui doit être exécutée de manière atomique. Ce maximum est appelé {PIPE_BUF}. Ce volume de IEEE Std 1003.1-2001 ne dit pas si les demandes d'écriture pour plus de {PIPE_BUF} octets sont atomiques, mais nécessite que les écritures de {PIPE_BUF} ou moins d'octets doivent être atomiques.

Answer 1

Je pense que, sur le plan technique, les appareils ne sont pas FIFOs, il est donc pas du tout clair que les garanties que vous citez sont censés appliquer.

Êtes-vous préoccupé par partiel écrit et lit dans un processus, ou lisez-vous et/ou écrivez-vous le même périphérique de différents processus? En supposant que ce dernier, vous feriez mieux de mettre en œuvre un processus de proxy de quelque sorte.Le proxy possède exclusivement le périphérique et effectue toutes les lectures et écritures, évitant ainsi entièrement le problème d'atomicité multi-processus. En bref, je conseille de ne pas essayer de vérifier que "lire/écrire à partir de cet appareil est en fait une opération atomique". Ce sera difficile à faire en toute confiance, et vous laisser avec une application qui est sujette à des échecs subtils si une version ultérieure de Linux (ou de tout autre O/S) ne parvient pas à implémenter l'atomicité comme vous le souhaitez.

Answer 2

Je pense que PIPE_BUF est la bonne chose. Maintenant, écrit de moins de PIPE_BUF octets ne peut pas être atomique, mais si ce n'est pas le cas, c'est un bogue du système d'exploitation. Je suppose que vous pourriez demander ici si un système d'exploitation a connu des bogues. Mais vraiment, si ça a un bug comme ça, ça devrait juste être réparé immédiatement.

Si vous voulez écrire plus de PIPE_BUF atomiquement, je pense que vous n'avez pas de chance. Je ne pense pas qu'il y ait un moyen, en dehors de la coordination et de la coopération, de faire en sorte que les écritures de plus grande taille soient atomiques.

Une solution à ce problème consiste à placer votre propre processus devant l'appareil et à vous assurer que tout le monde qui souhaite écrire sur l'appareil contacte le processus et lui envoie les données à la place. Ensuite, vous pouvez faire ce qui est logique pour votre application en termes de garanties d'atomicité.