The requirement for iot_uart_ioctl() with xUartRequest = eGetTxNoOfbytes or eGetRxNoOfbytes is not reasonable
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Ferma
- Stack tecnologico
- c
- Ambito
- api, embedded-iot
Direzione di ricerca
Inizia dalle definizioni di eGetTxNoOfbytes e eGetRxNoOfbytes in iot_uart.h, quindi leggi test/test_iot_uart.c per comprendere le operazioni asincrone concorrenti previste. Determina il comportamento previsto quando letture e scritture si sovrappongono e documenta la semantica concordata dell'API in iot_uart.h con test che coprano questa decisione.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Hello,
We are thinking of developing our own device driver as compliant to common-io-basic interface.
Among all, we are facing an issue with iot_uart_ioctl() definition as below.
Description
The requirement for iot_uart_ioctl() with xUartRequest = eGetTxNoOfbytes or eGetRxNoOfbytes is not reasonable.
Test Steps
N/A.
This is an issue with API definitions.
Target Revision
ddfb538 (or any version on and after 8151c98).
Details
iot_uart.h says eGetTxNoOfbytes (eGetRxNoOfbytes) requires "If the last operation was read, this returns 0" (If the last operation was write, this returns 0"). See below.
* @note eGetTxNoOfbytes returns the number of written bytes in last operation. * This is supposed to be called in the caller task or application callback, right after last operation completes. * This request expects 2 bytes buffer (uint16_t). * * - If the last operation was write, this returns the actual number of written bytes which might be smaller than the requested number (partial write). * - If the last operation was read, this returns 0. * * @note eGetRxNoOfbytes returns the number of read bytes in last operation. * This is supposed to be called in the caller task or application callback, right after last operation completes. * This request expects 2 bytes buffer (uint16_t). * * - If the last operation was read, this returns the actual number of read bytes which might be smaller than the requested number (partial read). * - If the last operation was write, this returns 0.
As test/test_iot_uart.c implies, we assume here you can call iot_uart_read_async() and iot_uart_write_async() concurrently.
In such concurrent call case, "the last operation" could change in an unexpected manner, and therefore the return value for eGetTxNoOfbytes/eGetRxNoOfbytes could be unreliable.
Imagine the events occur in the following order.
- (1) Call iot_uart_write_async()
- (2) Call iot_uart_read_async()
- (3) Async write operation is complete and the callback function is called with xOpStatus = eUartWriteCompleted
- (4) Call iot_uart_ioctl() with xUartRequest = eGetTxNoOfbytes
In (4), the guy who codes this does want to get the number of successfully written bytes in (1) and (3).
But according to iot_uart.h, this guy could get 0 in this case because "the last operation was(or could be) read".
Probably, this result is not what most people expect.
I suggest we remove "If the last operation was read, this returns 0" and "If the last operation was write, this returns 0" out of this definition.
What do you think of this idea ?
- Lingua principale
- C
- Stelle
- 16
- Fork
- 10
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Issue simili
-
After `require "openssl"`, a top-level `Digest` is `OpenSSL::Digest`, not the `Digest` moduleAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
ExpressLRS/ExpressLRS#3806 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100