Driver "Read" standard usage ('protocol')
Concerning "read", I would like to ask if there are specific standard
guidelines for using it, without bending it in a non-standard way:
A driver controls a Hardware-device (HW-device) which makes "16-byte
messages" available from time to time. If the HW-device has a "16-byte
message" available, it signals this via interrupt, causing the driver's
interrupt handler to load the message into the next slot in the driver's
Ring-Buffer (from where applications can then get the message).
_____________
|m1 |m2 | | - Ring-Buffer in driver
-------------
Message m3 will be loaded into the last slot.
Message m4 will overwrite m1.
etc.
Each message: 16 bytes
1)
If an application calls "read(fd, buffer, len)" with len < 16
then "ssize_t read()" will return -EINVAL, since a message must have a
multiple of 16 bytes.
2) BLOCKING:
If an application calls "read(fd, buffer, len)" with len = 16,
then the driver will run an instance of driver code ("ssize_t read()") on
behalf of the application. If a "16-byte message" is available in the
Ring-Buffer, it is delivered to the application and "ssize_t read()" returns
16. If no data is available in the Ring-Buffer, the instance will sleep
until an interrupt signals that the HW-device has new data (16 bytes). That
will cause the interrupt handler to load this 16-byte message to the next
free slot in the Ring-Buffer. The interrupt handler will then wake the
application's instance, so that it can deliver the message (from the
Ring-Buffer Slot) to the application. "ssize_t read()" then returns 16.
3)
If an application calls "read(fd, buffer, len)" with len = 32,
then the "application's driver instance" will sleep until a "16-byte
message" is available in the Ring-Buffer. Then the instance will deliver
those 16 bytes to the application.
If in the mean time, a second "16-byte message" has now become available,
the instance delivers this 2nd "16-byte message" to the application and
"ssize_t read()" returns 32.
If however, no second "16-bytes message" is available, the instance notes
that it has only provided 16 of 32 bytes (note "QQQ"- marker) and "ssize_t
read()" returns 16.
The application will then (like cat) call "read(fd, buffer, len)" again,
with len = 16, to receive the remaining 16 bytes. If a new "16-byte message"
is available, it is delivered to the application (then the note "QQQ" is
removed) and "ssize_t read()" returns 16.
OTHERWISE: If still no new data was available the INSTANCE DOES NOT SLEEP
(since it has noted "QQQ") and "ssize_t read()" will (remove the note "QQQ")
and then return 0.
The application then knows that no new data is available. Nonetheless, if
the application still wants the next 16 bytes, it will start a new round,
again calling "read(fd, buffer, len)" with len = 16, which will now cause
the instance to block (note removed), until these 16 bytes are available.
4)
If an application calls "read(fd, buffer, len)" with len = 17,
then the instance will block until 16 bytes become are available - then the
instance will deliver the data to the application and "ssize_t read()" (will
note "QQQ" and) will returns 16.
The application (like cat) will now call "read(fd, buffer, len)" with len =
1.
In the instance, "ssize_t read()" will (remove the note) and return -EINVAL,
since a message must have a multiple of 16 bytes.
Is this a standard, correct behavior?
I would especially like to know about 3), where the driver notes "QQQ", so
that it knows that the application definitely has at least 16 bytes, and
that further read calls should NOT BLOCK.
Thanks,
Albert
