anon... anon.al wrote:
> 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
Nice point put up. Nice because i was also thinking about it. :) But I
have another question
what is the standard implementation pattern for driver when the number
of bytes arriving
are not known? For example, variable number of data arriving on each
interrupt? Should application
always read with default number of bytes? Or poll n select is the best
option?
-Regards
Himanshu
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
